Re: configure sets CFLAGS or how to disable default CFLAGS='-g -O2' for gcc?

[Ralf Corsepius]

On Tue, 2006-04-04 at 12:12 -0400, Chris Pickett wrote:
> On Tue, April 4, 2006 11:13 am, Ralf Corsepius wrote:
> > The problem is portability.
> >
> >
> > The "-g -O2" autoconf uses is nothing but a default, which is known to
> > be safe on the majority of platforms and therefore is likely to be safe as
> > a compromise between "optimization" and "non-optimization".
> >
> > Anything else is beyond autoconf's scope and beyond your knowledge.
> 
> [...]
> 
> > In short: You have opened a can of worms, you'd better avoid.
> 
> Ok, two things.  First, the Automake manual does describe in some detail
> setting CFLAGS (and CPPFLAGS, and so on); see the FAQ entry at the end
> about the ordering differences.  If there is a difference between Autoconf
> and Automake for specifying different lists of CFLAGS that makes Automake
> better for it,
Nope, their is no such difference. Automake just uses autoconf.

>  I'm failing to see what it is (in particular, because I
> want to avoid repetition).  If there is no difference then it appears by
> your arguments that the documentation and even support for AM_CFLAGS,
> AM_CPPFLAGS, etc. is broken.
I don't understand.

AM_CFLAGS/AM_CPPFLAGS are supposed to take additional flags a package's
author wants to add (hard-coded) to CFLAGS rsp. CPPFLAGS. 

Portability, optimization and architecture dependent compiler flags are
a different issue. 

A package's author must have them in mind when using
AM_CPPFLAGS/AM_CFLAGS.

So, if you really want to add architecture- or compiler-specific flags
to AM_CPPFLAGS/AM_CFLAGS, you'd have to implement proper and safe checks
inside of your configure script, or you're better off avoiding the
problem and leave it to users.

However, from my experience, implementing proper and safe checks is
close to impossible. Not even relying on the fact of using GCC or a
particular architecture is feasible. In longer terms, any "games" with
optimization or arch-flags are likely to fail.

> Second, how am I actually meant to deal with this situation:
> 
> 1) I want one set of CFLAGS for all builds that specifies a lot of strictness
> 2) I want one set of additional CFLAGS for debugging/profiling builds
> 3) I want one set of additional CFLAGS for optimized/release builds
> 4) I am willing to change the sets by hand depending on compiler+compiler
> version detected; it will be gcc in most if not all cases; I'm also
> willing to force compiler upgrades on others.
> 5) I'd like configure to let me choose between debugging and optimization
> (I'll give this up if there is some other easy way).
The general answer to all these points would be: Let the user run
multiple configuration runs, one for each configuration.

...
mkdir debug
cd debug
../src/configure CFLAGS=<cflags> CPPFLAGS=<cppflags>
...

> And I thought I was being *good* by not clobbering the environment CFLAGS!
That's true. Permanently clobbering the environment with CFLAGS, in many
cases is harmful, but temporarily doing so, when invoking a command from
the shell (CFLAGS=<...> configure) or passing CFLAGS as argument to
configure (configure CFLAGS=<...>) doesn't clobber your environment.

All this does is to cause the configure script to pick up your CFLAGS
and to propagate it into the files it generates (Makefiles).

> I guess what's so surprising to me is that in practice I've rarely
> encountered an Autotools project that doesn't try to mess with CFLAGS in
> some way.  No, I don't have the same breadth of experience as you folk.
Let me put it this way: Wrt. CFLAGS, there exist a lot of broken
configure scripts, which effectively outsmart themselves. 
In most cases these only temporarily work on those systems, a package's
developers have access to and fail badly on other systems or will fail
at some point in future.

Ralf