Subject: Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics

From: Eric Blake <[email-masked]>
Date: Sat, 19 Jan 2013 07:25:35 -0700

On 01/19/2013 06:10 AM, Stefano Lattarini wrote:
> [-cc automake-patches]
> 
> On 01/16/2013 06:48 PM, Paul Eggert wrote:
>> On 01/16/13 04:46, Stefano Lattarini wrote:
>>> Makes sense.  Should I try to implement something along these lines (might
>>> take a few days), or are you planning to do that yourself (in which case
>>> I'll avoid the duplicated efforts)?
>>
>> I wasn't planning on doing that, so please go ahead.
>>
> Here is my attempt.  OK to go in Autoconf 2.70?

Close, but I have some ideas for improvements.

> 
> +- AC_PROG_CC_C_O implements saner semantics if the new witness macro
> +  AC_PROG_CC_C_O_USE_MODERN_SEMANTICS is defined (see the documentation
> +  for details).  Future versions of autoconf might make such new
> +  semantics the default at some point.

Thnking about a forward-compatibility issue - what happens if, when we
switch semantics, someone still needs to get back to the old semantics?
 Do we add yet another witness macro at that time?  And how does such a
package work with both old and new autoconf at once?

Rather, a better plan is to make AC_PROG_CC_C_O be configurable via a
single witness, by taking an optional argument that determines _which_
semantics to use and having the witness be a non-empty string to alter
defaults.  All existing versions of autoconf ignore macro arguments to
AC_PROG_CC_C_O, so we can add an optional argument, and document it as
follows:

===============
AC_PROG_CC_C_O([mode])
----------------------
If MODE is given with the value 'sane', use the new semantics (for 2.70
and beyond). If MODE is given with the value 'old' (or for 2.69 and
earlier), use the backwards-compatible semantics.  If MODE is omitted,
which of the two semantics will default to the value of the macro
AC_PROG_CC_C_O_MODE (for 2.70 and beyond).

AC_PROG_CC_C_O_MODE
-------------------
This macro is predefined in autoconf 2.70 to have the value 'old'; but
packages may redefine it to contain 'sane' to impact how AC_PROG_CC_C_O
will behave if called without arguments.  A future version of autoconf
may switch this macro to have the value 'sane'.
==============

Usage wise, a configure.ac that uses AC_PROG_CC_C_O([old]) will always
have old semantics, regardless of which autoconf version it is built
with.  A configure.ac that uses AC_PROG_CC_C_O without arguments (most
existing scripts) will default to old semantics under older automake;
but Automake 1.14 can do 'm4_define([AC_PROG_CC_C_O_MODE], [sane])' at
initialization time, to take advantage of sane semantics.

Implementation-wise, it would look something like this in autoconf 2.70
(rough draft):

m4_define([AC_PROG_CC_C_O_MODE], [old])
m4_defun([AC_PROG_CC_C_O],
[m4_if(m4_default([$1], [m4_default(AC_PROG_CC_C_O_MODE, [old])]),
  [old], [old semantics],
  [new semantics])])

or, if we wanted to reject invalid input (rather than silently treating
all strings != 'old' as 'sane'):

m4_define([AC_PROG_CC_C_O_MODE], [old])
m4_defun([AC_PROG_CC_C_O],
[m4_case(m4_default([$1], [m4_default(AC_PROG_CC_C_O_MODE, [old])]),
  [old], [old semantics],
  [sane], [new semantics],
  [m4_fatal([unrecognized mode: $1])])])

Either way, you need only switch one line in a future autoconf to
default to new semantics.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org