[subexp-daq] Possible problem in Makefile of NURDLIB

[Håkan T Johansson]

On Mon, 15 Apr 2024, Hans Toshihide Törnqvist wrote:

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

I would agree that warnings are very distracting, and whenever I see them 
I have an urge to fix them.  So they should not be issued when it is ok 
that a feature is 'missing'.  Since Nurdlib can be well used for systems 
where no VULOM / TRLOII is around, it would not be nice to warn by 
default.

The automatic configuration of features I like, but indeed, sometimes the 
easily missing pieces are quite irritating.

How about not making it mandatory to ask for features, but one could have 
some additional make targets that check for the existence of certian 
features.  In this case, e.g.

make require-trloii   # (or require_trloii)

which would depend on the default (all) target, but also fail with an 
error code if (in this case) nurdlib did not find trloii.

The other critical piece (also in trloii / drasi) would be the hardware 
mapping method that is compiled in.  That has a tendency to go missing, in 
case the needed library is not in the include path.

--

In drasi and trloii I changed the 'showconfig' target to only show a few 
options (actually one - the harware mapping method).  showconfig_all as 
before shows all autoconfiguration results.

Cheers,
Håkan