[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cleaning up AC_PROG_CC_C_O semantics

From: Stefano Lattarini
Subject: Re: Cleaning up AC_PROG_CC_C_O semantics
Date: Mon, 14 Jan 2013 20:56:57 +0100

Hi Paul.

On 01/14/2013 08:45 PM, Paul Eggert wrote:
> On 01/14/13 02:24, Stefano Lattarini wrote:
>> Autoconfers, WDYT?
> I think I'm lost.  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378
> is a long thread.
Yeah, sorry for not giving a more clear summary.

Here are the main grips I (and I guess Nick too) have with the current
AC_PROG_CC_C_O semantics:

  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?

  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?

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),
with a new one perhaps -- but public and documented this time, rather
than just an hack for Automake to exploit.

So, is the question clearer now?  If yes, what is your opinion?


reply via email to

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