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