Re: Automake-installed auxiliary scripts can get silently out-of-date after an Automake upgrade

[Stefano Lattarini]

Hi Eric.

On 06/26/2012 06:29 PM, Eric Blake wrote:
> On 06/26/2012 10:15 AM, Stefano Lattarini wrote:
>
>> What about this: since the great majority of the packages out there do
>> not seem to override nor patch the Automake-provided auxiliary scripts,
>> we could just make automake always reinstall such scripts by default;
>> and allow the users to mark scripts that are not to be reinstalled
>> this way (maybe a new autoconf macro -- "AM_BUILD_AUX_FILES_LOCAL", or
>> something similar buth with a better name).
>>
>> How does that sound?
>
> The whole idea of using the latest-and-greatest version of a script is
> to ensure that we pick up any upstream bug-fixes in that script, even
> when using an unpatched older distro automake.
>
With the same line of reasoning, you might want to use the perl modules
and '.am' Makefile fragment coming from Automake 1.12 while still using
Automake 1.11 [1], because of the enhancements and bugfixes they
are likely to carry.  Not a good idea, and certainly not one Automake
should strive to support.  The same goes for most Automake-provided
scripts IMO.

[1] Yes, that can be done passing the '--libdir' option to the automake
    invocation, without needing to patch Automake manually.  Not that
    it would be a good idea ...

> This idea makes sense
> for scripts that are generically useful (ie. you _always_ want the
> latest-and-greatest config.guess),
>
Which BTW Automake syncs from externals sources, so no problems of
backward-compatibility there (unless they are introduced by such
external upstream).

> but I concur that for internal details it is not as important.
>
Not only it's not important, but it could carry subtle issues, as
we've seen here.  Or as have already been experienced by GNU awk:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11203>

>>
>>> Either the build-aux
>>> scripts are heavily tied to a specific automake version
>>>
>> Most of them are, yes.  And should be considered internal details.
>> Such files are:
>>
>>   - elisp-compile
>>   - py-compile
>>   - mdate-sh
>>   - missing
>>   - ylwrap
>>   - test-driver
>>   - tap-driver.sh
>>   - tap-driver.pl
>
> Does the --help output (or at least the introductory comments) for these
> scripts mention that these are scripts necessary for correct operation
> of an automake-generated Makefile, but not independently useful?  It
> might be worth setting proper expectations.
>
This is a good idea.  Care to write a patch?  Otherwise I will do that
myself in the next(ish) days.

>>
>> Other files are more generally useful, and thus less likely to undergo
>> "gratuitous" backward incompatibilities:
>>
>>   - ar-lib
>>   - compile
>>   - depcomp
>>   - install-sh
>>   - mkinstalldirs
>
> The division that you have listed here seems reasonable.
>
Oh, BTW, note that mkinstalldirs is basically superseded by install-sh, and
only kept for backward-compatibility (it is gone in Automake-NG).  So it's
probably not a good idea to move it to Gnulib.  It should just be left to
bit-rot in Automake.

>>
>>> (and thus should not be shipped as independent scripts mirrored in gnulib),
>>>
>> In fact, I cannot understand why files like 'ylwrap' and 'missing'
>> (only useful to implement some automake internals) are being mirrored
>> in Gnulib ...
>>
>
>>> maybe it is better to remove the mirroring of 'missing' in gnulib, and
>>> to fix GNU M4 to use automake rather than gnulib for obtaining its copy
>>> of 'missing' during bootstrap.
>>>
>> Yes please!
>
> Sounds like we're in violent agreement, then.  I'll go ahead and prepare
> a gnulib patch, as well as fixing GNU M4 to quit relying on gnulib for
> 'missing' (it may mean repairing M4's bootstrap script to run automake
> --install, which has not previously been the case).  But I will also go
> ahead and post the formal automake patch that tries to restore the
> measure of back-compat.
>
>>
>> If we need a genuinely generic and stable script that offers some of
>> the features of 'missing', it should be implemented in gnulib -- then,
>> if possible, it will be automake which will start syncing it from the
>> gnulib repo.
>
> For the scripts that you mentiones, like 'install-sh', which are
> generically useful, should we go ahead and re-home them to have gnulib
> instead of automake be the canonical upstream?
>
I think this is would be a good move.  If you plan to go ahead with that,
note that there are some tests in the Automake testsuite that should be
moved as well.  I'm willing to hep with such a move; just ping me when
you're ready.

Thanks,
  Stefano