bug-m4
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Automake-installed auxiliary scripts can get silently out-of-date af


From: Eric Blake
Subject: Re: Automake-installed auxiliary scripts can get silently out-of-date after an Automake upgrade
Date: Tue, 26 Jun 2012 10:29:12 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

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.  This idea makes sense
for scripts that are generically useful (ie. you _always_ want the
latest-and-greatest config.guess), but I concur that for internal
details it is not as important.

> 
>> 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.

> 
> 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.

> 
>> (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?

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]