Hi :)
just a small bug report, there are some .stamp files that got included in the release by accident. I noticed because it caused build problems, likely only due to the fact that my build process copied the files once, changing the mtimes in the process.
% tar tf nettle-3.5.1.tar.gz | grep '.stamp$' nettle-3.5.1/testsuite/test-rules.stamp nettle-3.5.1/desdata.stamp
Cheers, Justus
Justus Winter justus@sequoia-pgp.org writes:
just a small bug report, there are some .stamp files that got included in the release by accident. I noticed because it caused build problems, likely only due to the fact that my build process copied the files once, changing the mtimes in the process.
Some stamp files are included intentionally, to avoid precisely that type of problems. See the note on stamp-h.in in the autoconf manual for one well documented example: https://www.gnu.org/software/autoconf//manual/autoconf-2.64/html_node/Automa...
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
Justus Winter justus@sequoia-pgp.org writes:
just a small bug report, there are some .stamp files that got included in the release by accident. I noticed because it caused build problems, likely only due to the fact that my build process copied the files once, changing the mtimes in the process.
Some stamp files are included intentionally, to avoid precisely that type of problems. See the note on stamp-h.in in the autoconf manual for one well documented example: https://www.gnu.org/software/autoconf//manual/autoconf-2.64/html_node/Automa...
I read the reference, and I don't see how it applies here. For the record, this is the build failure that I'm referring to:
% tar xf nettle-3.5.1.tar.gz % cp -r nettle-3.5.1 nettle % cd nettle % ./configure [...] % make [...] f="./`basename rotors.h`"; \ ./desdata rotors.h > ${f}T; \ test -s ${f}T && mv -f ${f}T $f /bin/sh: 2: ./desdata: not found make[1]: *** [Makefile:327: rotors.h] Error 1 make[1]: Leaving directory '/tmp/foo/nettle' make: *** [Makefile:46: all] Error 2
Cheers, Justus
Justus Winter justus@sequoia-pgp.org writes:
I read the reference, and I don't see how it applies here.
Right, it's a bit different.
For the record, this is the build failure that I'm referring to:
% tar xf nettle-3.5.1.tar.gz % cp -r nettle-3.5.1 nettle % cd nettle % ./configure [...] % make [...] f="./`basename rotors.h`"; \ ./desdata rotors.h > ${f}T; \ test -s ${f}T && mv -f ${f}T $f /bin/sh: 2: ./desdata: not found
This is a bit subtle, and maybe it can be improved. Let me explain how it's supposed to work.
rotors.h and keymap.h are generated by the desdata program, built from the desdata.c source file. They're not platform dependent in any way, so they're distributed with the tarball. When building from the tarball, there's no need to regenerate them, and the desdata program isn't built.
Now dependencies for this is a bit tricky. One obvious alternative is
rotors.h: desdata ./desdata ...
That has the drawback that it will needlessly build desdata and regenerate the files when building from a tarball, since the desdata executable obviously shouldn't be in the tarball. Another alternative is
rotors.h: desdata.c $(MAKE) desdata ./desdata ...
That breaks make -j, because if rotors.h and keymap.h are regenerated in parallel, we'll get two processes trying to build and run desdata at the same time, resulting in spurious errors.
Hence the redirection via desdata.stamp, to ensure that we only have one process building desdata. And now it seems that results in a failure if the build directory is in the state that desdata.stamp is newer than both desdata.c and rotors.h and but ./desdata doesn't exist.
Not sure how to fix that. A workaround is to copy with cp -a, which ensures that you won't attempt to rebuild *any* of the generated files in the tarball, including config.h.in and configure. Might also help a bit to reorder the files in the tarball, but I wouldn't recommend depending on that.
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
Justus Winter justus@sequoia-pgp.org writes:
I read the reference, and I don't see how it applies here.
Right, it's a bit different.
For the record, this is the build failure that I'm referring to:
% tar xf nettle-3.5.1.tar.gz % cp -r nettle-3.5.1 nettle % cd nettle % ./configure [...] % make [...] f="./`basename rotors.h`"; \ ./desdata rotors.h > ${f}T; \ test -s ${f}T && mv -f ${f}T $f /bin/sh: 2: ./desdata: not found
This is a bit subtle, and maybe it can be improved. Let me explain how it's supposed to work.
rotors.h and keymap.h are generated by the desdata program, built from the desdata.c source file. They're not platform dependent in any way, so they're distributed with the tarball. When building from the tarball, there's no need to regenerate them, and the desdata program isn't built.
I understand the part of the files being generated by the helper, and the role the .stamp file has in this. What I don't understand is the desire to generate them at package time, because surely it isn't that expensive. Yes, you have to be a bit careful in the case of cross-compilation, but that should be doable.
Hence the redirection via desdata.stamp, to ensure that we only have one process building desdata. And now it seems that results in a failure if the build directory is in the state that desdata.stamp is newer than both desdata.c and rotors.h and but ./desdata doesn't exist.
Not sure how to fix that. A workaround is to copy with cp -a, which ensures that you won't attempt to rebuild *any* of the generated files in the tarball, including config.h.in and configure. Might also help a bit to reorder the files in the tarball, but I wouldn't recommend depending on that.
I understand how changing the timestamps breaks this mechanism. And the build system I adopted doesn't actually use cp, I just demonstrated the problem using cp. Therefore, it is not as easy as using -a instead of -r.
In any case, I'm just going to delete any .stamp files in my build process. And I wanted to be a good downstream user and report what I perceived as a packaging hickup.
Cheers, Justus
Justus Winter justus@sequoia-pgp.org writes:
And the build system I adopted doesn't actually use cp, I just demonstrated the problem using cp. Therefore, it is not as easy as using -a instead of -r.
In any case, I'm just going to delete any .stamp files in my build process.
I would recommend that you either arrange to preserve timestamps, or delete all generated files that make knows how to recreate. Otherwise, the steps performed by make during the build will depend on the order in which the files happened to be copied, which seems brittle.
And I wanted to be a good downstream user and report what I perceived as a packaging hickup.
Thanks. I wasn't aware if this failure mode. I don't see any great solution.
It would be nice if one could tell make that there's a dependency chain
foo.c --> foo --> bar
and that foo (the executable) is unimportant. That should mean that as long as bar is more recent than foo.c, there's no need to remake bar, and no need to remake foo, no matter if foo happens to be out-of-date or non-existent. The stamp file is a workaround, and as you noticed, it's not perfect. Is there a better way?
Regards, /Niels
nettle-bugs@lists.lysator.liu.se
-
Justus Winter -
nisse＠lysator.liu.se