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

[Chris Pickett]

Ralf Corsepius wrote:
> On Tue, 2006-04-04 at 12:12 -0400, Chris Pickett wrote:
> > 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.

Ok.  It would be nice of you to add a note to the relevant FAQ entry in
the Automake manual explaining all of this.

> > 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>
> ...

Yes, but I am also the user, running the package on several different
platforms.  Separate aggressively optimized and special 
debugging/profiling builds are important: this is a research project 
where final numbers do matter because I'm (optimistically hoping I will 
be) publishing them.

I want to make life easy for myself, so to ease both development and 
collection of results, using your recommended technique, I would end up 
getting the command-line flags from scripts that recognized my current 
platform and compiler.  Pretty soon this starts to look an awful lot 
like what Autoconf provides anyway, and for me, the developer/user, it 
still just seems easier inside configure.ac and my Makefile.am's.

I guess the key assumption I'm making is that the user is willing to
edit the build system, which is currently the case.

And, it also seems to me the problem is that, in general, there is no 
portable way of specifying compiler flags.  Shifting the problem onto 
the user's shoulders doesn't really do anything for me because they are 
the same shoulders!

> > 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).

There was a confusion here.  I meant to say "command-line CFLAGS"
instead of "environment CFLAGS".  The Automake manual specifically says
not to clobber whatever the command-line CFLAGS are, to let the user
have the last say, and I was trying to do that by using AM_CFLAGS and 
friends.

> > 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.

Well, the most complicated configure.ac that I am familiar with is this
one, and it works on something like 13 different architectures:

http://sablevm.org/svn/repository/sablevm/trunk/configure.ac

Yeah, it clobbers the user/command-line CFLAGS (by appending instead of 
prepending), and it's not the cleanest thing in the world, but it allows 
for several different configure options that seem to work out quite 
nicely (I wrote very little of that configure.ac, but I use it a lot). 
I particularly like how --enable-debugging-features takes care of a lot 
of stuff for me.

Thanks for the discussion,
Chris