[email protected] (Niels Möller) writes:

> Justus Winter <[email protected]> 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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Reply via email to