bug-autoconf
[Top][All Lists]
Advanced

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

Re: Cleaning up AC_PROG_CC_C_O semantics


From: Paul Eggert
Subject: Re: Cleaning up AC_PROG_CC_C_O semantics
Date: Mon, 14 Jan 2013 19:16:10 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2

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.



reply via email to

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