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?
Thanks,
Stefano
