automake-patches
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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