[Top][All Lists]
[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
signature.asc
Description: OpenPGP digital signature