Re: Intel compiler and autoconf

[Tim Van Holder]

On Wed, 2002-10-30 at 19:36, David Mathog wrote:
> > 
> > >From what I read in the thread you attached, the Intel engineers
> > feel this is the result of bad configure invocation, and I'm inclined
> > to agree with them.  You set CPP in the environment, overriding any
> > value configure may have otherwise tried to deduce, and the value you
> > supplied was incorrect. 
> 
> Why?  icc can work as a preprocessor.  Oh, I see now - CPP isn't
> just the program name, it's the program plus a flag.  Autoconf
> uses two inconsistent formats for handling program name/command
> line options.  In some cases they are cleanly separated:
> 
> CC,CFLAGS
> CXX,CXXFLAGS
> CCLD,LDFLAGS

Not really.  I could set CC to 'gcc -V 2.95.2' if I wanted
to force the use of gcc 2.95.2 (on a system that has multiple
versions of gcc installed).  In all these cases, the variable
holds a program name plus optional options that, combined,
produce a command that has the required effect.
For example, if libtool is used, I would not be surprised if
CC was 'libtool --mode=compile' and CCLD was 'libtool --mode=link'.
Heck, if you had some weird setup and didn't want to pollute PATH,
you could have a footool script that could run your compiler(s)
and linker with the necessary environment and then set CC, CXX,
CCLD to 'footool cc', 'footool c++' and 'footool ld', respectively.
Configure will (currently) never use such things on its own though,
as the only thing it can reliably detect is 'real' compilers.

> and in others:
> 
> CPP

This is only different from CC in that it has an extra possibility
to check; aside from figuring out if there is a 'cpp'-like program
installed, it can also try $CC -E, as many compilers support that syntax
to act as preprocessor (some even have ONLY that syntax, and no external
cpp).

> INSTALL

This isn't really different at all, it just defaults to a
program+options value.

-- 
Tim Van Holder <address@hidden>
Anubex