GNU bug report logs - #13378
Make the 'subdir-objects' setup the default, and only available one

Previous Next

Full log

Message #85 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, 13378 <at> debbugs.gnu.org,
	"automake-patches <at> gnu.org" <automake-patches <at> gnu.org>
Subject: Re: [PATCH] compile: use 'compile' script when "-c -o" is used with
	losing compilers
Date: Fri, 11 Jan 2013 11:19:55 -0700

[Message part 1 (text/plain, inline)]

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
> -@code{AC_PROG_CC_C_O} 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/

> +@emph{retired 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).

> +@item AM_PROG_CC_C_O
> +@acindex AM_PROG_CC_C_O
> +@acindex 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 (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.