[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: |
Stefano Lattarini |
Subject: |
Re: Automake-installed auxiliary scripts can get silently out-of-date after an Automake upgrade |
Date: |
Tue, 26 Jun 2012 18:15:36 +0200 |
On 06/26/2012 05:37 PM, Eric Blake wrote:
> [adding bug-m4]
>
> On 06/26/2012 05:23 AM, Stefano Lattarini wrote:
>
>>>> I'm almost inclined not to do so, to force the affected
>>>> projects' broken setup to be fixed; i.e., if you are using Automake 1.11,
>>>> you let it install the correct 'missing' program, instead of forcing it
>>>> to use the 'missing' from Automake 1.13.
>>>
>>> But developers don't have the impression that they are doing something
>>> wrong when they use an old 'missing' program.
>
> In fact, this is how GNU M4 got into this predicament in the first
> place. Since I noticed with GNU M4 that 'missing' wasn't automatically
> updated when moving to a newer automake, I made the change months ago to
> have GNU M4 pick up the latest version of missing from gnulib rather
> than the version that shipped with the currently-installed automake; in
> this way, GNU M4 did not need to rerun 'automake --force', when running
> with a newer version of automake, but just automatically picked up the
> new build of 'missing' - this worked up until this week's changes broke
> backwards compatibility where a newer 'missing' was incompatible with an
> older automake. Maybe it's a bug in m4's bootstrap procedures for
> relying on a symlink to the latest 'missing' from gnulib instead of
> using 'automake --force --install' to install things, but I can't help
> but wonder how many other packages might have similar issues.
>
>>> No warning. How is a developer meant to notice that he's doing something
>>> wrong if 'automake -Wall' does not tell him?
>>>
>> This is actually a good point. When you upgrade your build system to
>> a new Automake version, you should run automake with the "--force" option,
>
> But if I'm relying on the automake shipped by my distro, then I'm at the
> mercy of when the distro decides to upgrade to a new automake version.
> It isn't obvious that just because some other tool was updated that I
> now have to rerun with a --force option.
>
>> to ensure that the automake-installed scripts are updated even if they
>> are already present in the build tree. But if you fail to do so, you
>> don't get any warning, which is not very user-friendly and can cause such
>> hard-to-spot errors.
>>
>> Any idea for a simple solution to this problem?
>
> Aren't there timestamps in the auxiliary scripts for a reason? If a
> script is updated as part of a new automake release, can't automake
> insert some sanity checks to see if the currently-installed scripts have
> too old of a timestamp, and complain about (or even better, auto-update)
> those scripts that don't match the newer automake?
>
Hmm... I wouldn't consider this solution as "simple" honestly.
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?
> 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
Other files are more generally useful, and thus less likely to undergo
"gratuitous" backward incompatibilities:
- ar-lib
- compile
- depcomp
- install-sh
- mkinstalldirs
> (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 ...
> or they are
> independently useful (we should not be breaking features used by older
> automake, and newer automake should be doing sanity checks that the
> newer features are present before relying on the newer features). I'm
> not sure whether 'missing' is independently useful outside of automake;
> 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!
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.
Thanks,
Stefano