[subexp-daq] Possible problem in Makefile of NURDLIB

[Weber, Guenter Dr.]

Looks like a good 'compromise' to me :-)

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


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