bug-autoconf
[Top][All Lists]
Advanced

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

Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics


From: Stefano Lattarini
Subject: Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics
Date: Wed, 16 Jan 2013 13:46:22 +0100

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



reply via email to

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