Re: [PATCH 1/r47] maint: help2man targets should rely on the binaries they call.

[Gary V. Vaughan]

On 23 Sep 2010, at 03:40, Ralf Wildenhues wrote:
> Hello Gary,

Hallo Ralf,

Thanks for the swift reviews again.

> * Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 10:29:44PM CEST:
>> On 23 Sep 2010, at 00:35, Ralf Wildenhues wrote:
>>> * Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 07:05:48PM CEST:
>>>> * Makefile.am (doc/libtool.1, doc/libtoolize.1): Don't rely on
>>>> the intermediate files, since they might have changed without
>>>> giving make the opportunity to update the actual binaries that
>>>> help2man calls in time.
>>> 
>>> No, because 'libtool' is created in the build tree, and the manpages are
>>> distributed.  Distributed files may not depend on undistributed files,
>>> as that breaks building from a read-only source tree.  Moreover,
>>> help2man is something the user is expected to not have to install prior
>>> to building Libtool.
>> 
>> Yuck.  Another reason to always start afresh after making changes
>> rather than relying on make to DTRT :(
>> 
>> In my case, ltmain.sh was corrupted, but even though I fixed it,
>> rerunning make ended up leaving the empty manpages generated by
>> a libtool script that had no --version output, and *then* it
>> proceeded to rebuild ltmain.sh.
> 
> I can try to debug it, if you can show me how to reliably reproduce the
> failure.

Thanks.

Rather than me chasing my tail trying to tickle that bug again, let's
skip this particular patch for now.  I pushed it to the front of my
queue because it was straight forward and I didn't think it relied on 
any of my other patches... but quite possibly, the fault is introduced
later in one of the Makefile.am changes further down my queue, in
which case we'll trip over the bug again soon enough, and can work out
a proper fix for it at that time.

>> Is there no way to make sure help2man doesn't run until the
>> programs it wants to call have been rebuilt, rather than building
>> (and potentially distributing) manpages documenting options from the
>> previous script?
> 
> I outlined four separate possible approaches for this in another mail in
> this thread already.

Except that you ruled out two of them, one involves giving up the
advantages of non-recursive make, and the last is already in use! :-p

Cheers,
-- 
Gary V. Vaughan (address@hidden)

PGP.sig
Description: This is a digitally signed message part