Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics

[Stefano Lattarini]

Hi Eric.

On 01/19/2013 03:25 PM, Eric Blake wrote:
> 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.
> 
> [SNIP]
>
All your suggestions sound good, but I won't have time to fix my patch
to accommodate them in the short term.  If you want to take over from
here, feel free to; otherwise, let's put this topic on hold for the
moment.

Thanks,
  Stefano

Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics

[Eric Blake]

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



signature.asc
Description: OpenPGP digital signature

Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics

[Stefano Lattarini]

[-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?

Thanks,
  Stefano

 8<  8<  8<  8<  8<  8<  8<  8<  8< 

>From 6d20ebf0abd4e08f0c7793d36d57ac9037026e05 Mon Sep 17 00:00:00 2001
Message-Id: 
<6d20ebf0abd4e08f0c7793d36d57ac9037026e05.1358600662.git.stefano.lattar...@gmail.com>
From: Stefano Lattarini 
Date: Sat, 19 Jan 2013 13:32:44 +0100
Subject: [PATCH] AC_PROG_CC_C_O: allow for improved semantics

The current semantics of AC_PROG_CC_C_O have two serious shortcomings,
that make the use of that macro in Automake problematic:

 1. It checks that *both* 'cc' and '$CC' (which might easily be 'gcc'
or 'clang') supports "-c -o" together.  Why?  If the user has a
broken base vendor compiler, but has installed a better one (say
GCC), why should he still be penalized?  This behaviour is very
likely only due to historical reasons, and has no good rationale
today.

 2. The name of the cache variable used by this macro is based on the
contents of the $CC expansion, rather than following the usual
'ac_cv_cc_*' pattern.  This is fragile and confusing.  In addition,
none of the other cache variables referring to check on the
selected C compiler has this property -- so why should this one?
Again, no good reasons come to mind (apart for "historical" ones).

For backward-compatibility reasons, we can't change these behaviours
abruptly; so, we implement a new saner behaviour, but don't make it
the default yet, instead allowing the user to explicitly request it
by defining the witness macro 'AC_PROG_CC_C_O_USE_MODERN_SEMANTICS'.
Future versions of Automake will thus define that macro to enable the
desired behaviour.

As a consequence of this change, we can drop the Automake-specific
private (and hacky) hook that has been added to AC_PROG_CC in past
commit 'v2.69-63-gce48964': Automake no longer plan to use it.

This change has been motivated by the on-going work on Automake and
its 'subdir-object' mode (see automake bug#13378).  See also:


* NEWS: Update.
* doc/autoconf.texi: Likewise.
* lib/autoconf/c.m4 (AC_PROG_CC_C_O): If the witness macro
'AC_PROG_CC_C_O_USE_MODERN_SEMANTICS' is defined:
  - check support for "-c -o" only for the currently selected C
compiler '$CC', and not also the "system" one 'cc'
  - unconditionally use 'ac_cv_prog_cc_c_o' as the cache variable
for this check, instead of a cache variable name based on the
expansion of $CC.
(AC_PROG_CC): Drop Automake-specific hook enabled when the
witness macro '_AM_PROG_CC_C_O_HELPME' was defined.

Signed-off-by: Stefano Lattarini 
---
 NEWS  |  5 +
 doc/autoconf.texi | 31 ---
 lib/autoconf/c.m4 | 46 ++
 3 files changed, 43 insertions(+), 39 deletions(-)

diff --git a/NEWS b/NEWS
index a9b2226..9e18436 100644
--- a/NEWS
+++ b/NEWS
@@ -28,6 +28,11 @@ GNU Autoconf NEWS - User visible changes.
 - AC_PROG_CC_STDC, AC_PROG_CC_C89, AC_PROG_CC_C99 have been marked as obsolete.
   Applications should use AC_PROG_CC.

+- 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.
+
 - AC_FUNC_VFORK now checks for the signal-handling bug in Solaris 2.4 'vfork'.
   Formerly, it ignored this bug, so that Emacs could use some tricky
   code on that platform.  Solaris 2.4 has not been supported since
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index bb83443..c1e89d7 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -7304,17 +7304,34 @@ needless reexpansion (@pxref{One-Shot Macros}).
 @acindex{PROG_CC_C_O}
 @cvindex NO_MINUS_C_MINUS_O
 @caindex prog_cc_@var{compiler}_c_o
+@caindex prog_cc_c_o
 If the C compiler does not accept the @option{-c} and @option{-o} options
-simultaneously, define @code{NO_MINUS_C_MINUS_O}.  This macro actually
-tests both the compiler found by @code{AC_PROG_CC}, and, if different,
-the first @code{cc} in the path.  The test fails if one fails.  This
-macro was created for GNU Make to choose the default C compilation
-rule.
+simultaneously, define @code{NO_MINUS_C_MINUS_O}.

-For the compiler @var{compiler}, this macro caches its result in the
+This macro has two modes of behavior, the historical one and a new
+sanest one, both described just below.  The historical mode is the
+default for the moment, but this might change in future autoconf
+versions.

Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics

[Stefano Lattarini]

On 01/16/2013 07:24 PM, Eric Blake wrote:
> On 01/16/2013 10:48 AM, 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.
> 
> Didn't you already add _AM_PROG_CC_C_O_HELPME; is that a sufficient
> witness macro for whether to use the proposed cleanups?
> 
Indeed that is enough for Automake's current needs.  But that hook is
currently in AC_PROG_CC, while Nick's proposal involved having something
like that in AC_PROG_CC_C_O, for which AM_PROG_CC_C_O would continue to
be a thin wrapper (but automatically invoked by AC_CONFIG_COMMANDS_PRE
whenever needed).

Regards,
  Stefano

Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics

[Eric Blake]

On 01/16/2013 10:48 AM, 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.

Didn't you already add _AM_PROG_CC_C_O_HELPME; is that a sufficient
witness macro for whether to use the proposed cleanups?

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



signature.asc
Description: OpenPGP digital signature

Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics

[Paul Eggert]

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.

Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics

[Stefano Lattarini]

On 01/15/2013 04:16 AM, Paul Eggert wrote:
> On 01/14/2013 11:56 AM, Stefano Lattarini wrote:
>>   1. It checks that *both* 'cc' and '$CC' (which might easily be 'gcc'
>>  or 'clang') supports "-c -o" together.  Why?  If the user has a
>>  broken base vendor compiler, but has installed a better one (say
>>  GCC), why should he still be penalized?
> 
> I don't know.  It's been that way for two decades or so, for no
> reason that I can see.
>  
>>   2. The fact the cache variable used by the test is based on the
>>  contents of the $CC expansion seems fragile and confusing.  AFICS,
>>  none of the other cache variables referring to check on the
>>  selected C compiler has this property -- so why should this one?
> 
> Again, no good reason that I can see.
> 
>> So, my question is: could any of this semantics be improved in the
>> obvious way in Autoconf 2.70?  If this is not doable in the pre-existing
>> macro for backward-compatibility considerations (and risking to introduce
>> incompatibilities a last minute change might indeed not be a good idea),
> 
> We could have the change take effect only if some other macro is invoked,
> indicating that the user wants the new behavior.  That should be safe.
> The default behavior can be the old behavior for now, with the intent that
> this will eventually change to the new behavior.
> 
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)?

Thanks,
  Stefano