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