<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:14pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Looks like a good 'compromise' to me :-)</p>
<div id="x_Signature">
<div style="font-family:Tahoma; font-size:13px"></div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag von Håkan T Johansson <f96hajo@chalmers.se><br>
<b>Gesendet:</b> Montag, 15. April 2024 23:56:39<br>
<b>An:</b> Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
<b>Betreff:</b> Re: [subexp-daq] Possible problem in Makefile of NURDLIB</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
On Mon, 15 Apr 2024, Hans Toshihide Törnqvist wrote:<br>
<br>
> Dear Günter,<br>
><br>
> On 2024-04-15 12:51, Weber, Guenter Dr. wrote:<br>
>> Dear Håkan,<br>
>> <br>
>> <br>
>> thank you very much for the explanations and the modifications.<br>
>> <br>
>> <br>
>> I see that you updated the automatic determination of the VULOM4_FW <br>
>> variable in the NURDLIB Makefile. Just for clarification: it will always <br>
>> come up with the VULOM4B version, even though there might be a VULOM4 <br>
>> module in the setup, as the firmware for both modules is identical for <br>
>> the purpose of this compilation, right?<br>
>> <br>
>> <br>
>> Moreover, to make things more comfortable for the user, I added the <br>
>> following code to the Makefile:<br>
>> <br>
>> <br>
>> ifeq (,$(TRLOII_PATH))<br>
>> TRLOII_PATH_TEST:=$(shell pwd)/../trloii<br>
>> ifeq ("$(wildcard $(TRLOII_PATH_TEST))", "")<br>
>> TRLOII_ERROR:=WARNING: Makefile guessed $(TRLOII_PATH_TEST), but folder <br>
>> does not exist!<br>
>> $(call infovar,TRLOII_ERROR)<br>
>> else<br>
>> TRLOII_PATH:=$(TRLOII_PATH_TEST)<br>
>> endif<br>
>> endif<br>
>> <br>
>> This assumes that it is unlikey that you want to compile NURDLIB without <br>
>> TRLOII being present. But maybe, if it is desired to decide if NURDLIB <br>
>> should compile with or without TRLOII it is better to have this as an <br>
>> explict option for "make" instead of doing it implicitly by having the <br>
>> TRLOII_PATH variable being set by hand or not.<br>
><br>
> If ../trloii exists and nconf runs as expected this works also on <br>
> non-VME systems. But I'm not too keen on having this warning where this <br>
> is an expected outcome. Will think about it.<br>
<br>
I would agree that warnings are very distracting, and whenever I see them <br>
I have an urge to fix them. So they should not be issued when it is ok <br>
that a feature is 'missing'. Since Nurdlib can be well used for systems <br>
where no VULOM / TRLOII is around, it would not be nice to warn by <br>
default.<br>
<br>
The automatic configuration of features I like, but indeed, sometimes the <br>
easily missing pieces are quite irritating.<br>
<br>
How about not making it mandatory to ask for features, but one could have <br>
some additional make targets that check for the existence of certian <br>
features. In this case, e.g.<br>
<br>
make require-trloii # (or require_trloii)<br>
<br>
which would depend on the default (all) target, but also fail with an <br>
error code if (in this case) nurdlib did not find trloii.<br>
<br>
The other critical piece (also in trloii / drasi) would be the hardware <br>
mapping method that is compiled in. That has a tendency to go missing, in <br>
case the needed library is not in the include path.<br>
<br>
--<br>
<br>
In drasi and trloii I changed the 'showconfig' target to only show a few <br>
options (actually one - the harware mapping method). showconfig_all as <br>
before shows all autoconfiguration results.<br>
<br>
Cheers,<br>
Håkan</div>
</span></font>
</body>
</html>