[subexp-daq] Possible problem in Makefile of NURDLIB

[Håkan T Johansson]

Dear Günter,

we think that we have managed to solve the issues at hand (there were 
multiple):

- The missing TRIDI compile: r3bfuser compiles (unconditionally) with both
   tridi and vulom support if it compiles with one of them.  (tridi is a
   module with similar hardware as the vulom).  Now the compile
   instructions also include to get the tridi things compiles.

- The VULOM4_FW now only picks one version, which should be enough.
   Those named _trlo actually have the same register layout, and
   find_firmwares.pl point them to the same, so any should do.

(Please see the updated instructions in the other mail.  Only the 
compilation sequence had additions, not the download parts.  But nurdlib 
and r3bfuser repositores need to be updated.

For this:

> Reporting compilation errors when they happen and why they happen would 
> be really very much appreciated

I am not sure what can be done when the issues are within the 
feature-finding builds.  I.e., when those fail, it just means that 
certains options are not available.  Problem is when later programs rely 
on them.

if anything, the later programs should then produce more specific errors 
telling what they are missing.  That might be doable with some #error 
macros, if they do not have complex makefiles to find features.

The other thing might be that 'make showconfig' is too cluttered.  There 
are essentially two kinds of features.  The uninteresting ones where the 
systems need to find one working option out of many.  If no option works, 
things will stop, as it cannot continue.

The more interesting selections are the ones where it can get away with no 
support, i. this case e.g. not compiling tridi support.

Perhaps one should have a 'make showconfig_all' which works as the one 
now, and 'make showconfig' only giving the important ones.

Cheers,
Håkan



On Fri, 12 Apr 2024, Weber, Guenter Dr. wrote:

> 
> Dear friends,
> 
> 
> on line 108 to 110 of the Makefile there is an automatic setting of the
> VULOM4_FW parameter:
> 
> 
>   ifeq (,$(VULOM4_FW))
>    VULOM4_FW:=$(shell ls $(TRLOII_PATH)/trloctrl | grep _trlo | $(SED)
> 's,fw_,,;s,_trlo.*,,')
>   endif
> 
> However, if I let this run (i.e. VULOM4_FW is not set by hand) the outcome
> is as follows:
> 
> 
> VULOM4_FW = "1409285e 68f8955e 6e4ba1a9 a73c5093 af33ed35"
> 
> 
> My understandig is that there should only be a single number selected
> (1409285e for VULOM4B and 6e4ba1a9 for VULOM4). I checked what the "ls"
> command produces on two systems:
> 
> 
> RIO4L-2 mbsdaq > ls $TRLOII_PATH/trloctrl
> Makefile  examples/  find_firmwares.pl*  firmwaredirs  fw_0866c243_rfx1/ 
> fw_1409285e_trlo@  fw_5e8f5ef4_tridi/  fw_68f8955e_trlo_all_in/ 
> fw_6e4ba1a9_trlo/  fw_a1729cda_rfx0/  fw_a73c5093_trlo@ 
> fw_af33ed35_trlo_big/  trloctrl.sh*  trlolib/
> 
> RIO4-MCAL-1 mbsdaq > ls $TRLOII_PATH/trloctrl
> Makefile  examples/  find_firmwares.pl*  firmwaredirs  fw_0866c243_rfx1/ 
> fw_1409285e_trlo@  fw_5e8f5ef4_tridi/  fw_68f8955e_trlo_all_in/ 
> fw_6e4ba1a9_trlo/  fw_a1729cda_rfx0/  fw_a73c5093_trlo@ 
> fw_af33ed35_trlo_big/  tridi_log.txt  trloctrl.sh*  trlolib/  vulom_log.txt
> 
> 
> RIO4L-2 is the one I am working on right now with the VULOM4, whereas
> RIO4-MCAL-1 is the system already running with VULOM4B.
> 
> 
> To me it looks like the code in the Makefile is not working as intended,
> right?
> 
> 
> 
> 
> 
> Best greetings
> 
> Günter
> 
> 
> 
>