[subexp-daq] Possible problem in Makefile of NURDLIB

[Hans Toshihide Törnqvist]

Dear Günter,

On 2024-04-15 12:51, Weber, Guenter Dr. wrote:
> 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.

If ../trloii exists and nconf runs as expected this works also on 
non-VME systems. But I'm not too keen on having this warning where this 
is an expected outcome. Will think about it.

Cheers,
Hans

> 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
>> 
>> 
>> 
>>
>