[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] compile: use 'compile' script when "-c -o" is used with losi
From: |
Eric Blake |
Subject: |
Re: [PATCH] compile: use 'compile' script when "-c -o" is used with losing compilers |
Date: |
Fri, 11 Jan 2013 11:19:55 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 |
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/
> 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.
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.
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 and/or issues warnings about being
obsolete, 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).
> 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; 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.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
- [PATCH] compile: use 'compile' script when "-c -o" is used with losing compilers, Stefano Lattarini, 2013/01/10
- Re: [PATCH] compile: use 'compile' script when "-c -o" is used with losing compilers,
Eric Blake <=
- Backward-compatibility in the autotools (was: Re: [PATCH] compile: use 'compile' script when "-c -o" is used with losing compilers), Stefano Lattarini, 2013/01/11
- Re: bug#13378: [PATCH] compile: use 'compile' script when "-c -o" is used with losing compilers, Stefano Lattarini, 2013/01/11
- Re: bug#13378: [PATCH] compile: use 'compile' script when "-c -o" is used with losing compilers, Stefano Lattarini, 2013/01/12
- Re: bug#13378: [PATCH] compile: use 'compile' script when "-c -o" is used with losing compilers, Nick Bowler, 2013/01/13
- Re: bug#13378: [PATCH] compile: use 'compile' script when "-c -o" is used with losing compilers, Stefano Lattarini, 2013/01/13
- [PATCH 2/2] Automatically call AM_PROG_CC_C_O as required., Nick Bowler, 2013/01/13
- Re: [PATCH 2/2] Automatically call AM_PROG_CC_C_O as required., Stefano Lattarini, 2013/01/13
- Re: [PATCH 2/2] Automatically call AM_PROG_CC_C_O as required., Nick Bowler, 2013/01/13