Discussion:
configure sets CFLAGS or how to disable default CFLAGS='-g -O2' for gcc?
Peter Volkov
2006-04-02 11:35:32 UTC
Permalink
Hello.

I'm using autoconf / automake to build my program. I'd like to set some
default CFLAGS for my project with the following variable in my
src/Makefile.am:

AM_CFLAGS = $(GLIB_CFLAGS) -O3 -Wall -ffast-math

The problem is that during compilation this default CFLAGS are hidden
with '-g -O2':

if gcc -DHAVE_CONFIG_H -I. -I. -I.. -pthread -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -O3 -Wall -ffast-math -g -O2 -MT
ry-psi-function.o -MD -MP -MF ".deps/ry-psi-function.Tpo" -c -o
ry-psi-function.o ry-psi-function.c; \
then mv -f ".deps/ry-psi-function.Tpo" ".deps/ry-psi-function.Po"; else
rm -f ".deps/ry-psi-function.Tpo"; exit 1; fi

My environment does not contain any CFLAGS. echo $CFLAGS gives nothing.
I found that the problem sits in configure script itself. The following
code seems defines CFLAGS and then substitutes it in Makefile.in:

ac_cv_prog_cc_g=no
fi
rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
fi
echo "$as_me:$LINENO: result: $ac_cv_prog_cc_g" >&5
echo "${ECHO_T}$ac_cv_prog_cc_g" >&6
if test "$ac_test_CFLAGS" = set; then
CFLAGS=$ac_save_CFLAGS
elif test $ac_cv_prog_cc_g = yes; then
if test "$GCC" = yes; then
CFLAGS="-g -O2"
else
CFLAGS="-g"
fi
else
if test "$GCC" = yes; then
CFLAGS="-O2"
else
CFLAGS=
fi
fi

So it sets CFLAGS... But why it does not revert before making
substitutions in Makefile.in? The only thing I can think about it the
order of macroses in my configure.ac:

AC_PREREQ(2.59)
AC_INIT([Rydberg Atom], 0.0.1, [***@mics.msu.su], ry-atom)
AC_LANG_C
AC_CONFIG_SRCDIR([src/ry-psi-function.h])
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_AUX_DIR([aux])
AC_CANONICAL_TARGET
AM_INIT_AUTOMAKE()
AM_CONDITIONAL([I686], [test "$target_cpu" = i686])
save_prefix="$prefix"
save_exec_prefix="$exec_prefix"
test "x$prefix" = xNONE && prefix=$ac_default_prefix
test "x$exec_prefix" = xNONE && exec_prefix=$prefix
if test "$target_cpu" = i686 ; then
ry_integ_dir=`eval echo ${datadir}/${PACKAGE}/x86`
RY_INTEG_DIR=${ry_integ_dir}
AC_DEFINE_UNQUOTED([RY_INTEG_DIR], "${ry_integ_dir}", [Integrals Path
Directory])
else
echo Unknown target arch.
fi
AC_SUBST([RY_INTEG_DIR])
prefix="$save_prefix"
exec_prefix="$save_exec_prefix"
AC_PROG_CC
AC_CHECK_LIB([m],[sqrt])
AM_PATH_GLIB_2_0(2.6.0,,AC_MSG_ERROR([
*** GLib 2.6 is required to build ry-atom; please make sure you have the
GLib
*** development headers installed. The latest version of GLib is
*** always available at http://www.gtk.org/.]),[gobject gthread])
AC_C_CONST
AC_CONFIG_FILES([Makefile
integrals/Makefile
integrals/x86/Makefile
scripts/Makefile
scripts/ry-build-figures.sh
scripts/build-r_avr_fixed_theta-in-dep-theta.sh
src/Makefile])
AC_OUTPUT
echo
echo "Building for target $target_cpu $target_vendor $target_os"
echo

Does anybody see what is the problem here? I do not want to set CFLAGS
environment variable forever... Any suggestions are welcome.

Another related question is what if I want to have different CFLAGS for
release and for debugging. How should I do this? I thought about
different AM_CFLAGS in Makefile.am and chose between them with
AM_CONDITIONAL, but now I don't know what to do.

BTW. I'm using autoconf 2.59 and automake automake 1.9.6.

Thank you for your time,
Peter.
Ralf Corsepius
2006-04-02 16:00:53 UTC
Permalink
Post by Peter Volkov
Hello.
I'm using autoconf / automake to build my program. I'd like to set some
default CFLAGS for my project with the following variable in my
AM_CFLAGS = $(GLIB_CFLAGS) -O3 -Wall -ffast-math
Very bad idea. These are architecture- and compiler-specific,
non-portable flags. You therefore should not set them anywhere.
Post by Peter Volkov
Does anybody see what is the problem here?
You are not applying the autotools correctly.
Post by Peter Volkov
I do not want to set CFLAGS
environment variable forever...
You don't have to. Don't try to mess up with CFLAGS inside of
configure.ac or Makefile.am and leave choosing CFLAGS to the user.

Only the user knows what he wants and needs on his platform.
Post by Peter Volkov
Any suggestions are welcome.
Another related question is what if I want to have different CFLAGS for
release and for debugging. How should I do this?
Leave choosing CFLAGS to the user/installer.

Ralf
Peter Volkov
2006-04-02 19:04:34 UTC
Permalink
Thank you for the answer, Ralf.
Post by Ralf Corsepius
Post by Peter Volkov
AM_CFLAGS = $(GLIB_CFLAGS) -O3 -Wall -ffast-math
Very bad idea. These are architecture- and compiler-specific,
non-portable flags. You therefore should not set them anywhere.
I'd like to use this flags in scientific (heavy usage of math functions)
application and -O3 makes difference here.
Post by Ralf Corsepius
You are not applying the autotools correctly.
Don't try to mess up with CFLAGS inside of
configure.ac or Makefile.am and leave choosing CFLAGS to the user.
Only the user knows what he wants and needs on his platform.
I do not need to create portable application here. But I'd like to use
autotools as the most flexible solution. I do not want to learn another
build system every time I change architecture ;), but it's hard to
imagine that I will need this particular program there.
Post by Ralf Corsepius
Post by Peter Volkov
Any suggestions are welcome.
Another related question is what if I want to have different CFLAGS for
release and for debugging. How should I do this?
Leave choosing CFLAGS to the user/installer.
I'm the user :)

Peter.
Chris Pickett
2006-04-02 17:06:30 UTC
Permalink
Post by Peter Volkov
I'm using autoconf / automake to build my program. I'd like to set some
default CFLAGS for my project with the following variable in my
AM_CFLAGS = $(GLIB_CFLAGS) -O3 -Wall -ffast-math
I wouldn't worry about -O3 and -ffast-math unless you are sure they will
make a difference.
Post by Peter Volkov
Does anybody see what is the problem here? I do not want to set CFLAGS
environment variable forever... Any suggestions are welcome.
Save CFLAGS before you call AC_PROG_CC, and restore it after, if you don't
want "-g -O2". Search the Autoconf list for AC_PROG_CC, there was a
fairly clean way of doing it suggested in the last couple of years. I
know this because I recently had a similar problem: I wanted -O0 as the
default. AC_PROG_CC has been doing this since 1996.
Post by Peter Volkov
Another related question is what if I want to have different CFLAGS for
release and for debugging. How should I do this? I thought about different
AM_CFLAGS in Makefile.am and chose between them with
AM_CONDITIONAL, but now I don't know what to do.
I use AC_SUBST in configure.ac to define STRICT_CFLAGS, BROKEN_CFLAGS,
DEBUG_CFLAGS and OPT_CFLAGS. Strict flags give as many gcc warnings as
possible, broken flags are those that don't play well for whatever reason
and can't be used everywhere (e.g. I link against a library with variadic
macros and so I have to put -Wno-variadic-macros in there, since I am
using -ansi -pedantic -Werror). Then to use these in a Makefile.am I do
AM_CFLAGS += @STRICT_CFLAGS@, for example; you could also have them
associated per-program.

You can use AC_ARG_ENABLE to get debugging and optimizing configure
options, which can then be used inside Makefiles, just look at some
examples of how this macro is used. The one thing you should avoid is
clobbering the environment CFLAGS in a configuration file, the end user
should always be able to override (at least the important bits of) what
you specified.

Cheers,
Chris
Peter Volkov
2006-04-02 19:04:53 UTC
Permalink
Post by Chris Pickett
Post by Peter Volkov
AM_CFLAGS = $(GLIB_CFLAGS) -O3 -Wall -ffast-math
I wouldn't worry about -O3 and -ffast-math unless you are sure they will
make a difference.
Yes. -O3 makes difference.
Post by Chris Pickett
Save CFLAGS before you call AC_PROG_CC, and restore it after, if you don't
want "-g -O2". Search the Autoconf list for AC_PROG_CC, there was a
fairly clean way of doing it suggested in the last couple of years. I
know this because I recently had a similar problem: I wanted -O0 as the
default. AC_PROG_CC has been doing this since 1996.
Great! This works :) Thank you!
Post by Chris Pickett
Post by Peter Volkov
Another related question is what if I want to have different CFLAGS for
release and for debugging. How should I do this? I thought about different
AM_CFLAGS in Makefile.am and chose between them with
AM_CONDITIONAL, but now I don't know what to do.
I use AC_SUBST in configure.ac to define STRICT_CFLAGS, BROKEN_CFLAGS,
DEBUG_CFLAGS and OPT_CFLAGS. Strict flags give as many gcc warnings as
possible, broken flags are those that don't play well for whatever reason
and can't be used everywhere (e.g. I link against a library with variadic
macros and so I have to put -Wno-variadic-macros in there, since I am
using -ansi -pedantic -Werror). Then to use these in a Makefile.am I do
associated per-program.
You can use AC_ARG_ENABLE to get debugging and optimizing configure
options, which can then be used inside Makefiles, just look at some
examples of how this macro is used. The one thing you should avoid is
clobbering the environment CFLAGS in a configuration file, the end user
should always be able to override (at least the important bits of) what
you specified.
Ralf, in his mail mentioned that any setting of CFLAGS in program should
be avoided, but in my current program such approach could be very
convenient. Thank you again!

Peter.
Ed Hartnett
2006-04-04 11:41:08 UTC
Permalink
Post by Peter Volkov
Post by Chris Pickett
Post by Peter Volkov
AM_CFLAGS = $(GLIB_CFLAGS) -O3 -Wall -ffast-math
I wouldn't worry about -O3 and -ffast-math unless you are sure they will
make a difference.
Yes. -O3 makes difference.
Post by Chris Pickett
Save CFLAGS before you call AC_PROG_CC, and restore it after, if you don't
want "-g -O2". Search the Autoconf list for AC_PROG_CC, there was a
fairly clean way of doing it suggested in the last couple of years. I
know this because I recently had a similar problem: I wanted -O0 as the
default. AC_PROG_CC has been doing this since 1996.
Great! This works :) Thank you!
Post by Chris Pickett
Post by Peter Volkov
Another related question is what if I want to have different CFLAGS for
release and for debugging. How should I do this? I thought about different
AM_CFLAGS in Makefile.am and chose between them with
AM_CONDITIONAL, but now I don't know what to do.
I use AC_SUBST in configure.ac to define STRICT_CFLAGS, BROKEN_CFLAGS,
DEBUG_CFLAGS and OPT_CFLAGS. Strict flags give as many gcc warnings as
possible, broken flags are those that don't play well for whatever reason
and can't be used everywhere (e.g. I link against a library with variadic
macros and so I have to put -Wno-variadic-macros in there, since I am
using -ansi -pedantic -Werror). Then to use these in a Makefile.am I do
associated per-program.
You can use AC_ARG_ENABLE to get debugging and optimizing configure
options, which can then be used inside Makefiles, just look at some
examples of how this macro is used. The one thing you should avoid is
clobbering the environment CFLAGS in a configuration file, the end user
should always be able to override (at least the important bits of) what
you specified.
Ralf, in his mail mentioned that any setting of CFLAGS in program should
be avoided, but in my current program such approach could be very
convenient. Thank you again!
In a similar situation, I first check to see if CFLAGS is set, then
only muck with it if it has not been set:

AC_MSG_CHECKING([whether configure should try to set CFLAGS])
if test "x${CFLAGS+set}" = xset; then
enable_cflags_setting=no
else
enable_cflags_setting=yes
fi
AC_MSG_RESULT($enable_cflags_setting)

then later...

test "x$enable_cflags_setting" = xyes && CFLAGS="$CFLAGS -q64"

This way, if the user sets CFLAGS, his choice is respected (though it
might make the build crash - but that's his problem).

If the user doesn't set CFLAGS, then I take the liberty of setting it
to what will work on his platform. (Otherwise he will just email me
and ask me how to set it, so this saves us all the trouble.)

Good luck!

Ed
--
Ed Hartnett -- ***@unidata.ucar.edu
Ralf Corsepius
2006-04-04 15:13:58 UTC
Permalink
Post by Ed Hartnett
Post by Peter Volkov
Post by Chris Pickett
Post by Peter Volkov
AM_CFLAGS = $(GLIB_CFLAGS) -O3 -Wall -ffast-math
I wouldn't worry about -O3 and -ffast-math unless you are sure they will
make a difference.
Yes. -O3 makes difference.
Yes, it can make the difference between a functional compiler invocation
and a failing one - However, you as the package author who doesn't have
access to the platform an installer/users is using have no chance to
know ;)

Packagers/installers/integrators however are supposed to know which
CFLAGS they want/need.
Post by Ed Hartnett
Post by Peter Volkov
Post by Chris Pickett
I use AC_SUBST in configure.ac to define STRICT_CFLAGS, BROKEN_CFLAGS,
DEBUG_CFLAGS and OPT_CFLAGS. Strict flags give as many gcc warnings as
possible, broken flags are those that don't play well for whatever reason
This invalidates all configure checks a configure script performs during
configuration, because it causes you to using different flags at
"configure-time" and "make-time".
Post by Ed Hartnett
Post by Peter Volkov
Post by Chris Pickett
You can use AC_ARG_ENABLE to get debugging and optimizing configure
options, which can then be used inside Makefiles, just look at some
examples of how this macro is used. The one thing you should avoid is
clobbering the environment CFLAGS in a configuration file, the end user
should always be able to override (at least the important bits of) what
you specified.
Ralf, in his mail mentioned that any setting of CFLAGS in program should
be avoided, but in my current program such approach could be very
convenient.
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.
Post by Ed Hartnett
In a similar situation, I first check to see if CFLAGS is set, then
AC_MSG_CHECKING([whether configure should try to set CFLAGS])
if test "x${CFLAGS+set}" = xset; then
enable_cflags_setting=no
else
enable_cflags_setting=yes
fi
AC_MSG_RESULT($enable_cflags_setting)
then later...
test "x$enable_cflags_setting" = xyes && CFLAGS="$CFLAGS -q64"
This way, if the user sets CFLAGS, his choice is respected (though it
might make the build crash - but that's his problem).
Well, IMO this is your problem and qualifies as a bug in your configure
script: You are providing a default that probably is invalid for most
compilers and is likely to cause building to fail or do something else
than you expect.
Post by Ed Hartnett
If the user doesn't set CFLAGS, then I take the liberty of setting it
to what will work on his platform. (Otherwise he will just email me
and ask me how to set it, so this saves us all the trouble.)
If you really want to do something like you do, you'd have to check the
compilerm, if it accepts "-q64" and if "-q64" actually does what you
expect it to do.

In short: You have opened a can of worms, you'd better avoid.

Ralf
Chris Pickett
2006-04-04 16:12:49 UTC
Permalink
Post by Ralf Corsepius
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.
[...]
Post by Ralf Corsepius
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, 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.

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

I'd like to listen to your advice, since obviously you know way more about
this than I do, but if the answer is "hand-craft your own portable
CFLAGS-setting system for use with configure" then basically I'm going to
abuse Autoconf/Automake because it's the least painful way I see of doing
it. And I thought I was being *good* by not clobbering the environment
CFLAGS!

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.

Cheers, and thanks,
Chris
Chris Pickett
2006-04-04 16:30:35 UTC
Permalink
Post by Chris Pickett
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.
Just to be clear, I mean this:

"What we recommend is that you define extra flags in separate variables.
For instance, you may write an Autoconf macro that computes a set of
warning options for the C compiler, and AC_SUBST them in WARNINGCFLAGS;
you may also have an Autoconf macro that determines which compiler and
which linker flags should be used to link with library libfoo, and
AC_SUBST these in LIBFOOCFLAGS and LIBFOOLDFLAGS."

which is exactly what I am doing.

Cheers,
Chris
Ralf Corsepius
2006-04-04 17:04:55 UTC
Permalink
Post by Chris Pickett
Post by Ralf Corsepius
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.
[...]
Post by Ralf Corsepius
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.
Post by Chris Pickett
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.
Post by Chris Pickett
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>
...
Post by Chris Pickett
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).
Post by Chris Pickett
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
Chris Pickett
2006-04-04 18:20:39 UTC
Permalink
Post by Ralf Corsepius
Post by Chris Pickett
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.
Post by Ralf Corsepius
Post by Chris Pickett
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!
Post by Ralf Corsepius
Post by Chris Pickett
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.
Post by Ralf Corsepius
Post by Chris Pickett
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
Jacob Meuser
2006-04-05 04:23:23 UTC
Permalink
Post by Chris Pickett
Post by Ralf Corsepius
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.
Post by Chris Pickett
Post by Ralf Corsepius
Post by Chris Pickett
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.
Post by Chris Pickett
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"
Post by Chris Pickett
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.
Post by Chris Pickett
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?
Post by Chris Pickett
Post by Ralf Corsepius
Post by Chris Pickett
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.
--
<***@jakemsr.com>
Chris Pickett
2006-04-05 05:28:23 UTC
Permalink
Post by Jacob Meuser
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.
I guess this is really it: I don't and can't know; there's just not
enough time to learn everything that my computer does. I fix things
when I find out they are problems. Of course I try to be proactive
about finding problems, primarily by testing early and often, but I'm
not perfect. For example, I didn't know AC_PROG_CC set "-g -O2", even
though I had been using it for a while.
Post by Jacob Meuser
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.
So, how about providing special flags for known platforms, and a safe
default for unknown platforms? Add to this protection by configure
options so the user really has to want my flags to get them. Is this an
acceptable compromise?
Post by Jacob Meuser
# 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.
Thanks for this example; I can imagine it gets much more complicated
when you start testing out program fragments to see that they don't break.
Post by Jacob Meuser
Post by Chris Pickett
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!
Yes, I see.
Post by Jacob Meuser
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?
For now, it's the case that I am the only user; hopefully in the future
that won't be so. Regardless, the Autotools are still useful right now
because they help me develop and build on multiple systems.
Post by Jacob Meuser
Post by Chris Pickett
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.
How about ./configure CFLAGS="-O2 -fno-omit-frame-pointer"?

But anyway, I think I see your point: don't piss off the user (and
ultimately make my job harder) by forcing them to use my compiler flags.
So, unless they specifically pass --use-my-brain-dead-opt-flags to
configure, they won't see any of them.

The whole irony of this that I actually wanted -O0 but AC_PROG_CC was
killing it. :)

Cheers,
Chris
Ralf Wildenhues
2006-04-05 06:40:58 UTC
Permalink
Post by Chris Pickett
For example, I didn't know AC_PROG_CC set "-g -O2", even
though I had been using it for a while.
Quoting info Autoconf "C Compiler":
| If using the GNU C compiler, set shell variable `GCC' to `yes'.
| If output variable `CFLAGS' was not already set, set it to `-g
| -O2' for the GNU C compiler (`-O2' on systems where GCC does not
| accept `-g'), or `-g' for other compilers.
Post by Chris Pickett
So, how about providing special flags for known platforms, and a safe
default for unknown platforms? Add to this protection by configure
options so the user really has to want my flags to get them. Is this an
acceptable compromise?
In general, overridability is more important than the special-casing.

Cheers,
Ralf
Chris Pickett
2006-04-05 07:03:28 UTC
Permalink
Post by Ralf Wildenhues
Post by Chris Pickett
For example, I didn't know AC_PROG_CC set "-g -O2", even
though I had been using it for a while.
| If using the GNU C compiler, set shell variable `GCC' to `yes'.
| If output variable `CFLAGS' was not already set, set it to `-g
| -O2' for the GNU C compiler (`-O2' on systems where GCC does not
| accept `-g'), or `-g' for other compilers.
I know that now, of course. What I meant was that I don't always read
or perhaps more importantly remember the full documentation for every
single command I use, especially when they appear to be working just
fine. It was in response to Jacob's, "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." That's all. I'm a human
catastrophe.
Post by Ralf Wildenhues
Post by Chris Pickett
So, how about providing special flags for known platforms, and a safe
default for unknown platforms? Add to this protection by configure
options so the user really has to want my flags to get them. Is this an
acceptable compromise?
In general, overridability is more important than the special-casing.
Okay.

I realize this whole discussion might be (is!) getting annoying, so I'll
try to be quiet again.

Cheers,
Chris
Ralf Wildenhues
2006-04-05 08:06:51 UTC
Permalink
Please accept my apologies if you feel I'm beating a dead horse.
Post by Chris Pickett
Post by Chris Pickett
For example, I didn't know AC_PROG_CC set "-g -O2", even
though I had been using it for a while.
I know that now, of course.
Oh, I only thought it useful to point out because AC_PROG_CC simply
doesn't always set CFLAGS to "-g -O2". (And while you may have known
that by the time I replied, other, possibly future, readers of this
thread may not.)
Post by Chris Pickett
What I meant was that I don't always read or perhaps more importantly
remember the full documentation for every single command I use,
especially when they appear to be working just fine.
While it would make a maintainer's job a lot easier much of the time,
I don't think anybody really expects that every user inhales the full
manual before using a tool. I usually try to search the documentation
for some keyword before asking; and it shows, too: whenever I chose a
bad keyword, I end up asking rather naive questions.. the list archives
can tell.
Post by Chris Pickett
I'm a human catastrophe.
Nobody implied anything like that, really. :-)

Cheers,
Ralf
Ed Hartnett
2006-04-05 00:31:16 UTC
Permalink
Post by Ralf Corsepius
Post by Ed Hartnett
test "x$enable_cflags_setting" = xyes && CFLAGS="$CFLAGS -q64"
This way, if the user sets CFLAGS, his choice is respected (though it
might make the build crash - but that's his problem).
Well, IMO this is your problem and qualifies as a bug in your configure
script: You are providing a default that probably is invalid for most
compilers and is likely to cause building to fail or do something else
than you expect.
No, this line of configure code is executed only on a system it will
work on.
Post by Ralf Corsepius
Post by Ed Hartnett
If the user doesn't set CFLAGS, then I take the liberty of setting it
to what will work on his platform. (Otherwise he will just email me
and ask me how to set it, so this saves us all the trouble.)
If you really want to do something like you do, you'd have to check the
compilerm, if it accepts "-q64" and if "-q64" actually does what you
expect it to do.
In short: You have opened a can of worms, you'd better avoid.
I would like to do it the autoconf way, but we use cfortran.h, which
requires a different value in CPPFLAGS for each fortran compiler.

If I don't have my configure script provide that parameter, the build
breaks and the user emails me.

Yes, in theory the user should read the documentation and pick the
right parameters themselves.

Ed
--
Ed Hartnett -- ***@unidata.ucar.edu
Jacob Meuser
2006-04-05 05:09:05 UTC
Permalink
Post by Ed Hartnett
Post by Ralf Corsepius
If you really want to do something like you do, you'd have to check the
compilerm, if it accepts "-q64" and if "-q64" actually does what you
expect it to do.
In short: You have opened a can of worms, you'd better avoid.
I would like to do it the autoconf way, but we use cfortran.h, which
requires a different value in CPPFLAGS for each fortran compiler.
If I don't have my configure script provide that parameter, the build
breaks and the user emails me.
maybe I misunderstand something here, but it sounds like you both
agree: add only flags that you know will work on the platform in
use.
--
<***@jakemsr.com>
Ralf Corsepius
2006-04-07 05:21:37 UTC
Permalink
Post by Jacob Meuser
Post by Ed Hartnett
Post by Ralf Corsepius
If you really want to do something like you do, you'd have to check the
compilerm, if it accepts "-q64" and if "-q64" actually does what you
expect it to do.
In short: You have opened a can of worms, you'd better avoid.
I would like to do it the autoconf way, but we use cfortran.h, which
requires a different value in CPPFLAGS for each fortran compiler.
If I don't have my configure script provide that parameter, the build
breaks and the user emails me.
maybe I misunderstand something here, but it sounds like you both
agree: add only flags that you know will work on the platform in
use.
To some degree you are right.
Post by Jacob Meuser
AC_MSG_CHECKING([whether configure should try to set CFLAGS])
if test "x${CFLAGS+set}" = xset; then
enable_cflags_setting=no
else
enable_cflags_setting=yes
fi
AC_MSG_RESULT($enable_cflags_setting)
then later...
test "x$enable_cflags_setting" = xyes && CFLAGS="$CFLAGS -q64"
I.e. he adds -q64 to CFLAGS if the user doesn't specify CFLAGS.

This is problematic, because he doesn't
1. Check if the compiler supports -q64
2. Doesn't check if -q64 actually does what he wants it to do.

-q64 might do what he wants on those platforms he uses as development
environment, but that's it:
* Compilers might not support -q64.
* -q64 might have different meanings for different compilers.
* -q64 could have different meanings for different architectures.

This will cause errors when building his package.

Ralf
Ed Hartnett
2006-04-08 18:14:23 UTC
Permalink
Post by Ralf Corsepius
Post by Ed Hartnett
AC_MSG_CHECKING([whether configure should try to set CFLAGS])
if test "x${CFLAGS+set}" = xset; then
enable_cflags_setting=no
else
enable_cflags_setting=yes
fi
AC_MSG_RESULT($enable_cflags_setting)
then later...
test "x$enable_cflags_setting" = xyes && CFLAGS="$CFLAGS -q64"
I.e. he adds -q64 to CFLAGS if the user doesn't specify CFLAGS.
Nah, I just cut out the rest of the code. That CFLAGS setting only
happens on one platform, when using the native compiler. (I forget
which one).
Post by Ralf Corsepius
This is problematic, because he doesn't
1. Check if the compiler supports -q64
2. Doesn't check if -q64 actually does what he wants it to do.
This is true. If the vendor makes sudden changes in how their compiler
works, then my configure script will not work correctly. In practice
this is rare, and just puts the user back in charge of the flags, so
nothing is lost by trying to set flags for users in cases where it can
work.

In any case, all that only happens if the user specifies
--enable-64bit on the configure command line, which leads my configure
script to turn on the correct flags for AIX, Irix, and Sun
platforms. (On other platforms it does nothing.)

As I've said, it's an imperfect solution, but, given that we have no
support staff, and our main support question was always something
like:

"How do I build netCDF in 64-bit mode with a PathScale compiler."

So I set the flags.

It would be better to tear apart cfortran.h (which is a third party
tool used to wrap C functions in fortran), and make it feature based
instead of platform based. But that is a huge job I just can't
handle given other commitments.
Post by Ralf Corsepius
-q64 might do what he wants on those platforms he uses as development
* Compilers might not support -q64.
* -q64 might have different meanings for different compilers.
* -q64 could have different meanings for different architectures.
This will cause errors when building his package.
Yep.

Ed
--
Ed Hartnett -- ***@unidata.ucar.edu
Steven G. Johnson
2006-04-11 22:06:59 UTC
Permalink
Post by Ed Hartnett
In a similar situation, I first check to see if CFLAGS is set, then
Yes, we do something similar in FFTW.

To those on this list who think that configure should never set CFLAGS,
realize that optimizing CFLAGS can be very important for
high-performance scientific programs and requiring the user to set them
is painful and error-prone. (Of course, you want the user to be able to
override them if necessary.)

See AX_CC_MAXOPT (http://autoconf-archive.cryp.to/ax_cc_maxopt.html) at
the macro archive for the macro that FFTW uses to set its flags
depending on the compiler vendor, architecture, etcetera.

Regards,
Steven G. Johnson

Loading...