<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 31 Jul 2019 at 08:56, Antony Antony <<a href="mailto:antony@phenome.org" target="_blank">antony@phenome.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi<br>
tangential to "make showversion" discussion, there is an issue that annoys <br>
me. Now I have a fix for it! If there is no violent opposition against this <br>
proposed patch I would like to apply the attached patch.<br>
<br>
version.c dependency is broken while developing and testing continuously from <br>
one directory. Current dependency works great if you always build from a <br>
clean git tree or run 'make clean' first or build from a tar ball. However, <br>
less ideal for continuous development and testing.<br>
<br></blockquote><div><br></div><div>Right, for the case where the version file really matters, it is correct.   See the bottom end of:</div><div><a href="https://lists.libreswan.org/pipermail/swan-dev/2016-August/001609.html">https://lists.libreswan.org/pipermail/swan-dev/2016-August/001609.html</a></div><div>This is also the least worst option.</div><div><br></div><div><div dir="ltr"><div>For instance, invoking 'make' on an up-to-date build should do 'nothing'.  With this patch applied, repeated makes will instead repeatedly rebuild all the programs.  In addition to being confusing, and misleading (what did I change, is a dependency broken) it is also wrong - it cascades as now the re-built programs are going to needlessly trigger other dependencies (for instance make check in cavp).</div><div><br></div><div>On KVMs, things get worse.  A sequence like (i.e., make certain things are up-to-date and then run a test):</div><div>   $ make kvm-install kvm-test KVM_TESTS=testing/pluto/basic-pluto-01</div><div>now has the additional overhead of both running git with the dirty check and against 9p (which I think we can all agree is expensive, but something we can't see since it is being hidden under a rock) and then build new executable.</div></div><div><br></div><div>The problem with git and KVM is also also why I've never bothered to fix this - any 'technically correct' solution will need to invoke 'git dirty' within the KVM - is that overhead really worth it - not for me?<br></div></div><div><br></div><div>Andrew</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Here is the case where it breaks.<br>
You run "make base install-base" starting with a clean git tree.<br>
Now make changes to the code and commit those changes.<br>
then "make base install-base". Now the  version.c would be stale.<br>
ie. pluto --version would not change even though the code changed, and <br>
commit id, or "make showversion" changed.<br>
<br>
./OBJ.linux.x86_64/programs/pluto/pluto --version<br>
Libreswan v3.28-526-g5c9063def5-master-s2 XFRM(netkey) esp-hw-offload FORK <br>
PTHREAD_SETSCHEDPRIO NSS (IPsec profile) DNSSEC FIPS_CHECK LABELED_IPSEC <br>
SECCOMP LIBCAP_NG LINUX_AUDIT XAUTH_PAM NETWORKMANAGER CURL(non-NSS)<br>
<br>
With this proposed patch version.c will be always (re)created.<br>
"make base' or make programs will have the correct version string.<br>
It would help me a lot. Are there any side effects if version.c is <br>
(re)created every time?<br>
<br>
Currently I use a work around, "make clean". it has two disadvantages.<br>
It would add another 30 - 180 sec delay for when you make a change <br>
re-compile.  Often I forget that and have back track double check.<br>
<br>
Let me know what you think. If there are no major objections to this patch I <br>
will apply it, if no comment in week I will apply it:) <br>
See the attached patch.<br>
<br>
-antony<br>
_______________________________________________<br>
Swan-dev mailing list<br>
<a href="mailto:Swan-dev@lists.libreswan.org" target="_blank">Swan-dev@lists.libreswan.org</a><br>
<a href="https://lists.libreswan.org/mailman/listinfo/swan-dev" rel="noreferrer" target="_blank">https://lists.libreswan.org/mailman/listinfo/swan-dev</a><br>
</blockquote></div></div>