Re: ac-archive: ax_cflags_<option> macros...

[Guido Draheim]

Ville Laurikari schrieb:
> > The reason: some compilers will happily accept "-v" or "+w1" for
> > something not intended - they are valid but they do not do what
> > we want, to just enable additional warning-options.
>
>
> Have there been problems with the way vl_prog_cc_warnings works?  At
> least I haven't heard about it... :)
>
> I'm not 100% sure now but I remember seeing a compiler somewhere that
> basically ignored any options it didn't recognize (gave a warning
> message about them though) and went ahead with whatever options it
> found.  So even with selector tests we cannot be sure that some
> compiler somewhere doesn't do something weird when being tested for
> options.  This is why I decided to go with grepping version strings
> first to avoid trouble since there are less chances of getting "cc -v"
> to do something drastic than "cc -some -option -for -some -compiler".

Not quite ;-) ... but you weren't actually grepping version
strings since a lot of "cc" compilers out there do not say
anything to describe themselves ;-) .. just to state a
matter of fact *sigh*

> > With this scheme, I have reworked the existing macros that I do
> > use widely to pick up this detection, and furthermore I did change
> > them all to a common result-scheme - they add to CFLAGS or CXXFLAGS
> > when no output-variable has been given as an argument. Note that
> > each of the following files contains two macros, one for adding to
> > CFLAGS (AX_CFLAGS_...) and one for C++ flags (AX_CXXFLAGS_...)
>
>
> Seems good to me.  Maybe we could go one step further and just
> generate some generic compiler identifier string which could then be
> used for anything, be it compiler options or something else...
> AX_PROG_CC_FLAVOR or something, sort of like config.guess but for
> compilers.   This could then be used in other macros to do the dirty
> work, and there would be only one place to update when compilers
> change.

Yes, I was thinking about that too - with one exception. If you read
the icc documention (intel's linux c/c++ compiler) then you will note
that the latest incarnation has started to pick up long-options of
the same name as gcc long-options and the very same meaning. It can be
furthermore noted that there exist specialized compilers for some
embedded systems that are derivatives from another one - they would
however identify themselves as being a different breed, whereas
they would still share a lot of commandline options with its parenting
compiler.

That makes it not the best choice to limit oneself to a list of compiler
names and choose the options by that - it is the very same scheme why
autoconf people have always argued against using "case $host" sequences
and have generic feature tests all around. In real life, well, we use
a mixed style - but a real feature test should always be preferred, and
I was hoping that the presented scheme is good enough in this respect.

thanks, and have fun, guido                    http://ac-archive.sf.net