bug#13378: Cleaning up AC_PROG_CC_C_O semantics

[Stefano Lattarini]

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