bug-gnulib
[Top][All Lists]
Advanced

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

Re: [PATCH] {master} missing: do not touch timestamps; only warn for out


From: Stefano Lattarini
Subject: Re: [PATCH] {master} missing: do not touch timestamps; only warn for out-of-date files
Date: Tue, 26 Jun 2012 09:43:28 +0200

Hi Eric.

On 06/26/2012 05:46 AM, Eric Blake wrote:
> On 06/20/2012 03:30 PM, Stefano Lattarini wrote:
>> Before this change, the missing script had a twofold role:
>>
>>   - it warned the user if some required maintainer tools was missing,
>>     or too old;
>>
>>   - in such a case, it tried to "fix" the timestamp of the files that
>>     should have been rebuilt by that tool (without actually updating
>>     the file contents, of course), to allow the build to continue.
>>
> 
>> +++ b/lib/missing
>> @@ -1,10 +1,10 @@
>>  #! /bin/sh
>> -# Common stub for a few missing GNU programs while installing.
>> +# Common wrapper for a few potentially missing GNU programs.
>>  
>> -scriptversion=2012-05-23.18; # UTC
>> +scriptversion=2012-06-14.10; # UTC
>>  
> 
>>  case $1 in
>> ---run)
>> -  # Try to run requested program, and just exit if it succeeds.
>> -  run=
>> -  shift
>> -  "$@" && exit 0
>> -  # Exit code 63 means version mismatch.  This often happens
>> -  # when the user try to use an ancient version of a tool on
>> -  # a file that requires a minimum version.  In this case we
>> -  # we should proceed has if the program had been absent, or
>> -  # if --run hadn't been passed.
>> -  if test $? = 63; then
>> -    run=:
>> -    msg="probably too old"
>> -  fi
>> -  ;;
> 
> Ouch.  You've broken programs that use automake < 1.12
>
< 1.13 actually.  This change is backward-incompatible (albeit slightly),
so it won't appear until the next major release.

> but which pull in
> the latest build-aux scripts via gnulib,
>
These projects were already broken IMHO.  Howe can you expect to blindly mix
auxiliary files from two different major releases (in this case not even
consecutive!) and expect things to work?

> since older automake hard-coded the use of the --run argument:
> 
> $ make
> CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh
> /home/remote/eblake/m4-branch/build-aux/missing --run aclocal-1.11 -I m4
> /home/remote/eblake/m4-branch/build-aux/missing: unknown '--run' option
> Try '/home/remote/eblake/m4-branch/build-aux/missing --help' for more
> information
> make: *** [aclocal.m4] Error 1
> 
> It should still be possible to configure a project using gnulib's oldest
> supported automake (I think that's even 1.9.6, thanks to RHEL 5 still
> being in popular use; but I ran into this on the quite-new Fedora 17
> where the installed automake is still 1.11.3), but coupled with the
> latest build-aux script versions.  Can we restore at least a measure of
> back-compatibility so that the new missing coupled with old automake
> doesn't fail miserably?
> 
While your patch is small and non-invasive enough that I wouldn't mind
applying it (with the addition of a proper comment telling why we still
support '--run'), 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 then, I don't want to make
other developers' life more difficult than it needs to be, so I'll take
the patch in the end (BTW, could you also slap a proper commit message
on it?  Thanks).  Still, I really like to see those projects' setups
fixed, to avoid similar issues in the future.

Regards,
  Stefano



reply via email to

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