Backward-compatibility in the autotools (was: Re: [PATCH] compile: use 'compile' script when "-c -o" is used with losing compilers)

[Stefano Lattarini]

On 01/11/2013 07:19 PM, Eric Blake wrote:
> On 01/10/2013 06:33 AM, Stefano Lattarini wrote:
>> Reference:
>> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#50>
>>
> 
>>  @acindex AC_PROG_CC_C_O
>> -This is like @code{AC_PROG_CC_C_O}, but it generates its results in
>> -the manner required by Automake.  You must use this instead of
>> address@hidden when you need this functionality, that is, when
>> -using per-target flags or subdir-objects with C sources.
>> +This is an @emph{obsolete wrapper} around @code{AC_PROG_CC_C_O}.  New
>> +code needs not to use this macro.  It might be deprecated and
> 
> s/needs not to/needs not/
>
Fixed, thanks.

>> address@hidden in future Automake versions}.
> 
> As a rule of thumb on when to remove a macro - I would personally like
> being able to write a configure script that works on both RHEL 5 (or
> CentOS 5) (autoconf 2.59, automake 1.9.6) as well as rawhide (eventually
> automake 1.14 and beyond), for as long as RHEL 5 remains a viable
> Enterprise-level distro.
>
I'm quite unconvinced of the value in trying to support this.  Developers
should just keep their tool reasonably up-to date IMHO; if they can't
do so through their package manager, they should do so by installing
from source.  And while I see this can be a problem for complex packages
like Perl [1] or GCC, it is easily done for package simpler to install,
like the autotools are.

 [1] I try to keep support for older Perl versions alive in Automake
     exactly because I've seen which pain is to correctly install Perl
     from sources.

> While it is fine to deprecate a macro, or even warn that its use is
> obsolete, what I _don't_ want is to have to jump through hoops to make
> my configure.ac/Makefile.am do conditionals that says if targetting
> older automake, use the older form, else use the newer form.  I would
> rather that I can just blindly use the older form, ignore the warnings,
> and still have things work.
>
For a while, this is ok.  In fact, I plan to have AM_PROG_CC_C_O start
issue warnings only in Automake 1.14, and be removed not before Automake
1.16.  But trying to keep a package working with Automake versions that
are six, seven years apart (as 1.9.6 and 1.13 are) is asking for trouble,
and not worth fighting too hard to support.

Also, in this case (as in the case for AM_PROG_MKDIR_P), a user still
wanting to use use the obsolete macro can simply define it in, say,
acinclude.m4.

> Someday, RHEL 5 will disappear, and/or upgrade to a newer set of
> autotools (I've been campaigning for the latter, and so has Jim Meyering
> - the build tools are a special beast, and our argument is that even for
> a long-term stable platform, newer build tools is in the platform's best
> interest); but until that happens, completely breaking back-compat is
> not perceived as very nice.
> 
> So even if the macro becomes a no-op
>
Which is as of today, but that is OK, since it does no harm to the users
nor the code base.

> and/or issues warnings about being obsolete,
>
This for sure won't happen before Automake 1.14.

> don't completely remove it, and don't force a user to delete
> their use of the macro (at least, not unless the user has indicated via
> AM_INIT_AUTOMAKE that they are willing to require 1.14 as a minimum
> automake version for processing their input files).
>
As for this, there is no hurry.

>> address@hidden AM_PROG_CC_C_O
>> address@hidden AM_PROG_CC_C_O
>> address@hidden AC_PROG_CC_C_O
>> +This is an @emph{obsolete wrapper} around @code{AC_PROG_CC_C_O}.  New
>> +code needs not to use this macro.  It will be deprecated, and then
>> +removed, in future Automake versions.
> 
> Again, removed is too harsh;
>
I believe it is necessary to really inform the users about upcoming
obsolescence, lest they got unwittingly bitten by the eventual deprecation
or removal.  So I'd really like to keep this harsh wording in place.  (Of
course, the macro will not be removed without having spent at least a major
release cycle as deprecated at runtime; having done a huge screw-up in that
regard has been enough for me).

> made a no-op and/or made into a warning
> (one which can be silenced for people knowingly being portable to older
> automake) is nicer.
> 
Which is why we will follow this road in the next two major releases.
But again, IMHO, that's is not a good reason not to warn users.

Regards,
  Stefano