On 08 Sep 2014, at 20:57 , Paul Eggert <eggert@xxxxxxxxxxx> 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. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
