Re: AC_PROG_CC wrongly setting $GCC=yes while clang is used

[Bastien Chevreux]

On 08 Sep 2014, at 20:57 , Paul Eggert <address@hidden> wrote:
> On 09/08/2014 11:36 AM, Bastien Chevreux wrote:
>> Which brings me to what sparked my initial mail to the list: is there 
>> somewhere in the autoconf system a macro which gives back the compiler 
>> family of the used compiler so that one can take some action?
> 
> That would not be The Autoconf Way. :-)
> 
> The Autoconf approach is to test for features, not to test for compiler 
> version and then infer features from the version.  If you need webbed feet, 
> then test for webbed feet; don't ask "Are you a duck?”.

I do see your point.

But it makes things *really* interesting for a configure.ac writer to take some 
action already during ./configure if one knows that, e.g., optimising with 
"-OMG” helps to speed your code 10 times for supercompiler 1.2.0 onwards, but 
not for 1.7.0 to 1.8.3 because of some weird compiler bug. And then users 
complain your program is worthless because of wrong results you didn’t even 
know could be produced. Been there, seen that, not funny.

And I’d say that often configure-writers do not think (or cannot think) of 
everything when writing checks. Continuing your example:

------
checking for webbed feet … yes
checking for pecker … yes
checking for can swim … yes
checking for can lay eggs … yes
perfect, your duck environment is ready, just type make.
$ make
error: ‘platypus’: unknown parameter ‘—quack’
------

Yeah, I know, he should’ve checked for ‘can quack’. Or ‘can fly’. Or ‘has 
feathers'. But not everyone knows that Down Under there are mammals who got 
pretty good at imitating duck features lately.

Joke aside: would there be, from the autoconf maintainers' side, the interest 
in actually having a module which would give back the compiler family? I’m 
thinking of writing one based on what I can see at 
http://sourceforge.net/p/predef/wiki/Compilers/

Best,
  B.