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

[Harald Dunkel]

Ralf Corsepius wrote:
> On Tue, 2005-09-27 at 12:53 +0200, Harald Dunkel wrote:
> 
>>Ralf Corsepius wrote:
>>
>>>Nope. You don't seem to have understood how things are working:
>>>
>>>AM_CFLAGS/AM_CXXFLAGS are supposed to take flags having been specified
>>>by a package's developer.
>>>
>>
>>Understood.
>>
>>
>>>CFLAGS/CXXFLAGS are suppoed to take flags having been specified by a
>>>package's installer. Here, "-g -O2" are just "sufficiently reasonable
>>>defaults", a package installer is supposed to override.
>>>
>>
>>So the user has to write
>>
>>      make CFLAGS= CXXFLAGS= install
>>
>>to get the default flags (AM_CXXFLAGS, etc.) provided by the developer?
>>Sorry, but this is weird.
> 
> It's not weird at all.
> 
> 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.

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

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)


Regards

Harri