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