> I do a lot of cross-compilation, where the platform requires a set
> of CFLAGS to always be present, such as -march=xxx and
> -isysroot=yyyy ...
Suggestion:
Set
CROSS = -march=xxx -isysroot=yyy
where you're currently trying to hack CFLAGS and have makefiles that
are actually going to use CFLAGS add $(CROSS) to it.
I would also discourage developers from setting CFLAGS directly from
the command-line - especially setting it to a value that should
plainly be in CPPFLAGS; -D... don't belong in CFLAGS in any case.
Instead, provide some other variable, that *isn't* the one to which
make gives built-in semantics, e.g. EXTRADEFS, and encourage
developers to pass down their extra defines via that.
Passing CFLAGS=-DB on the make command-line doesn't mean "include -DB
in the flags passed to the compiler": it says "don't give the compiler
any other flags than -DB". So you're trying to code make files that
support a highly mis-guided style of usage, and thus having to
over-use override. Rather than do that, provide a channel for doing
what folk really do want to do - supply some extra defines to the
preprocessor - and make sure they know about it. Then have
CPPFLAGS += $(EXTRADEFS)
so the preprocessor flags end up in the right place (instead of
CFLAGS) and tell anyone who's trying to configure compilation by
setting the wrong variables unilaterally on the command-line that
there's a better way and, no, you're not going to break everything so
that they can achieve the result they want by doing something
manifestly wrong, instead of the clean way you've provided.
Create a path of least resistance that consists of right behaviour,
then nudge developers out of industry-standard bad habits,
Eddy.
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
