Re: adding specific C flags for a SINGLE source file

[Sander Niemeijer]

On vrijdag, dec 10, 2004, at 16:58 Europe/Amsterdam, Kevin P. Fleming 
wrote:

> Sander Niemeijer wrote:
>
> > As a general remark, automake is not that clear in the precedence 
> > that compiler flags take (will FOOFLAGS come before or after 
> > AM_FOOFLAGS/target_FOOFLAGS) and if/how one would be able to overrule 
> > these flags. Important is also to notice that CXXFLAGS/CFLAGS or 
> > overruled by adding a new option at the end (e.g. '-O2 -O3' would end 
> > up meaning '-O3'), but with include/library search paths in 
> > CPPFLAGS/LDFLAGS it is exactly the other way around (e.g. '-Ifoo 
> > -Ibar' ends up meaning '-Ifoo' when you have a foo/foo.h and 
> > bar/foo.h). I think some notes about this in the documentation or FAQ 
> > would also be very helpful.
>
> Those precedence rules regarding -O, -I, -L and etc. have nothing to 
> do with the autotools, and everything to do with your toolchain. It 
> would not be practical to document any of this in the autotools docs 
> (since toolchains differ), nor would it even be relevant.

I have to disagree here.

automake choses an ordering for <target>_CFLAGS and CFLAGS, so it 
actually forces a precedence. The fact that this precedence cannot be 
altered, means that I cannot setup my toolchain the way I want it to. 
So the autotools have got _everything_ to do with how I am able to 
handle precedences.

> In other words, you need to understand how your toolchain processes 
> these flags before trying to understand how autotools usage of them 
> will affect your project.

Sure. But I am not suggesting that we should include the precedence 
rules for all possible toolchains in the autotools documentation.
The only thing we should be aware of is the fact that toolchains have 
these things called 'precedences'. And as a package developer you will 
have to deal with that if you start to insert your own (not supplied by 
the user) options in your build system. If the autotools wouldn't have 
any influence on how you would be able to handle these precedences, 
then you have a point. But considering the fact that automake actually 
places restrictions on what you are able to do (i.e. you can't override 
user provided optimization flags on a per target basis (because 
<target>_CFLAGS comes before CFLAGS), but you will be able to override 
a user provided include file search path (because <target>_CPPFLAGS 
comes before CPPFLAGS)), makes it valuable information to put in 
writing somewhere. And since this is automake specific, the automake 
documenation would be the most logical place IMO.

However, what I would like to see even more (although I am not sure 
whether it can be done in a clean way) is that these restrictions would 
just be removed. This could, for instance, be done by allowing a 
package developer to place both target specific options before and 
after a set of global options.
Something like: $(pre_<target>_..FLAGS) $(..FLAGS) 
$(post_<target>_..FLAGS)
In this way, you will be able to handle both left-to-right and 
right-to-left precedence issues.

Best regards,
Sander