|Subject:||Re: adding specific C flags for a SINGLE source file|
|Date:||Fri, 10 Dec 2004 21:04:49 +0100|
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
|[Prev in Thread]||Current Thread||[Next in Thread]|