[subexp-daq] Possible problem in Makefile of NURDLIB

[Weber, Guenter Dr.]

Dear Håkan,


thank you very much for the explanations and the modifications.


I see that you updated the automatic determination of the VULOM4_FW variable in the NURDLIB Makefile. Just for clarification: it will always come up with the VULOM4B version, even though there might be a VULOM4 module in the setup, as the firmware for both modules is identical for the purpose of this compilation, right?


Moreover, to make things more comfortable for the user, I added the following code to the Makefile:


ifeq (,$(TRLOII_PATH))
TRLOII_PATH_TEST:=$(shell pwd)/../trloii
ifeq ("$(wildcard $(TRLOII_PATH_TEST))", "")
TRLOII_ERROR:=WARNING: Makefile guessed $(TRLOII_PATH_TEST), but folder does not exist!
$(call infovar,TRLOII_ERROR)
else
TRLOII_PATH:=$(TRLOII_PATH_TEST)
endif
endif


This assumes that it is unlikey that you want to compile NURDLIB without TRLOII being present. But maybe, if it is desired to decide if NURDLIB should compile with or without TRLOII it is better to have this as an explict option for "make" instead of doing it implicitly by having the TRLOII_PATH variable being set by hand or not.






Best greetings

Günter


________________________________
Von: subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von Håkan T Johansson <f96hajo at chalmers.se>
Gesendet: Samstag, 13. April 2024 03:50:36
An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.
Betreff: Re: [subexp-daq] Possible problem in Makefile of NURDLIB


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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chalmers.se/pipermail/subexp-daq/attachments/20240415/80df9c06/attachment.html>