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

[Jacob Meuser]

On Tue, Apr 04, 2006 at 02:20:39PM -0400, Chris Pickett wrote:
> Ralf Corsepius wrote:

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

presumably, if you are adding stuff, you already know exactly why
you are adding it, exactly what it does, and exactly what the
consequences are.  no different than anything else in computing.

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

simpler for you, or someone else?  sure, you can make configure
do what you want, but then what about when _I_ get your source
distribution and try to build it on OpenBSD/sgi?

good luck figuring out what my problem is (-O3 is really iffy on
that platform) when I come asking you why your software is so buggy.
unless of course you can test and debug on OpenBSD/sgi, and anything
else someone might want to use your software on.

you really think this will be easier for you?

you want simple?  nothing is simpler than "default".

sure, if you are releasing _binaries_, you can build with whatever
CFLAGS, since presumably you are also testing the binaries.  but for
source distributions, it's best to be conservative.

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

huh?  the user can do

./configre CFLAGS="-O100 -fdo-whatever-on-this-platform"

> And, it also seems to me the problem is that, in general, there is no 
> portable way of specifying compiler flags.

huh?  it is difficult but not impossible.  just don't make assumptions
(and yes, adding _anything_ without knowing the full consequences
is making assumptions).

you need stuff like:

# only add -O3 on i386/gcc versions >= 3.0
if USING_GCC
if GCC_VERSION_3
if ARCH_I386
AM_CFLAGS="-O3"
endif
endif
endif

where USING_GCC, GCC_VERSION_3 and ARCH_I386 are being set in tests
in configure.  not the greatest example, but hopefully you get the
idea.

>  Shifting the problem onto 
> the user's shoulders doesn't really do anything for me because they are 
> the same shoulders!

so just do it in your script that runs configure.  trust me, adding
optimization flags is going to annoy people who are trying to build
your software on a platform you don't know about ... and you are
going to have a really hard time trying to help them, since you do
not know that platform!

see, adding these flags makes your job harder!

of course, if you are not planning on distributin the software, and
really only _you_ will be the user ... but then why would you be
using autotools in that case?

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

_but_, AM_CFLAGS will _always_ be added to the compile command.
if you have AM_CFLAGS="-O3 -fomit-frame-pointer", the user _cannot_
remove those without editing the build system.  you must check
that AM_CFLAGS is not going to cause problems on any platform your
software will be used on.

-- 
<address@hidden>