automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Force -O0 flags, inhibit the default -O2 flags


From: Sander Niemeijer
Subject: Re: Force -O0 flags, inhibit the default -O2 flags
Date: Wed, 28 Sep 2005 22:16:36 +0200


On woensdag, sep 28, 2005, at 17:04 Europe/Amsterdam, Harald Dunkel wrote:

autoconf sets CFLAGS/CXXFLAGS to "reasonable defaults", that's all. If
these defaults cause problems on your platforms, you have to override
them.


They cannot be called "defaults", if they get a higher priority
than the flags set in my Makefile.am. And I do not think that
setting CXXFLAGS='-g -O2' is a reasonable default, unless autoconf/
automake's assumption is that the user is supposed to debug the
developer's code.

IMHO the priorities for setting build flags should be (highest
first):
        1)      user
        2)      developer
        3)      autoconf/automake

Surely it is OK that autoconf/automake can provide default build
flags somehow, but the flags set by the developer (e.g. AM_CXXFLAGS)
should get a higher priority, if they are set. And automake/autoconf
should provide just the bare minimum.

As a developer you have full control over both AM_xxxFLAGS and xxxFLAGS variables. There is no ownership difference between these two types of flags from a developer/autoconf point of view. If you don't like the default for CXXFLAGS that autoconf choses then just replace it in the way Ralph explained:

CXXFLAGS=${CXXFLAGS-"<your other settings>"}

There is however an important difference between AM_xxxFLAGS and xxxFLAGS variables in the sense that a user should be able to override the xxxFLAGS variables by using ./configure xxxFLAGS=<some other value>, which is not true for AM_xxxFLAGS.

For this reason you should be careful that you only 'set' xxxFLAGS in the way mentioned above. When you as a developer define your CXXFLAGS these should function as a _default_ for users of your package (just as autoconf allows its default of '-g -O2' to be overruled). A user should always be able to provide its own CXXFLAGS when calling configure and these settings should override any default value for CXXFLAGS that a developer may have specified.

The way I see it, the place where AM_xxxFLAGS comes into play is when you want to _extend_ xxxFLAGS. Because of the way automake orders AM_xxxFLAGS and xxxFLAGS it can not be used to override flags (except for path specification flags where the leftmost entry takes precedence)

Suppose we need to extend CPPFLAGS with an additional -I entry. If this extension should be applied globally to the package you can add something like 'CPPFLAGS="-I<the directory> $(CPPFLAGS)"' in configure.ac. However, if an extension only makes sense within the scope of a single Makefile, then you can also add this -I option to the AM_CPPFLAGS of the Makefile.am file.



According to the documentation you (as a developer) are not allowed to
set CFLAGS/CXXFLAGS (Automake manual, 2.5, or GNU Coding Standards).

Yes, you as a package developer, are supposed to let them pass through
unchanged, if a user specifies them.


The documentation says that these flags are reserved for the user.
It does not say that these variables are reserved for the user and
for Automake. As a development tool, autoconf/automake has to follow
this rule, too. CXXFLAGS is off-limits. Or the documentation should
mention that autoconf/automake might predefine these flags in an
unpredictable manner (e.g. by adding -g to the compiler flags), and
that the developer has no chance to override this without violating
the GNU coding standard, or redefining Automake's internals.

You are perfectly free to provide your own _defaults_. What you shouldn't do is explicitly set these flags and thus overriding any xxxFLAGS settings that the user may have provided at configure time.



The GNU coding standard talks about developers and users only:

http://www.gnu.org/prep/standards/standards.html#Command-Variables

We have a 3rd party, namely autoconf/automake. IMHO the relation between
autoconf/automake and developer should be similar to the relation
between developer and user. The flags set by the developer (e.g.
AM_CXXFLAGS) can be extended or overriden by the user (by setting
CXXFLAGS). Similar to this it should be possible for the developer
to extend or override the flags set by autoconf/automake (????_CXXFLAGS)
by setting "his" flags (AM_CXXFLAGS).

This would mean that next to CXXFLAGS and AM_CXXFLAGS there should
be a 3rd variable to be set by autoconf/automake, e.g. AM_AM_CXXFLAGS.
The compile rules should be modified accordingly, e.g.

CXXCOMPILE = $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
        $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS)

                           ||
                          \||/
                           \/

CXXCOMPILE = $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
        $(AM_AM_CPPFLAGS) $(AM_CPPFLAGS) $(CPPFLAGS) \
        $(AM_AM_CXXFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS)

This is not necessary, just override the defaults from autoconf using the approach mentioned above.

Best regards,
Sander





reply via email to

[Prev in Thread] Current Thread [Next in Thread]