On Wed, Apr 04, 2007, Andreas Tille wrote: > Which I learned by this example and which makes me wonder whether > there is absolutely no way out to enforce overriding CFLAGS.
It is possible, but really a bad idea. See "override" in make. I really recommend you don't use it. > This makes no real sense because it concerns a relative path to > a subdirectory in the source tree that does not exist from > every subtree location. Add "-I $(top_src_dir)/somedir", not "-I somedir". > >change the upstream build to use its internal CFLAGS and still honor > >"user" (that's you) provided CFLAGS. For an explanation on why the > >upstream build should honor CFLAGS but not use them, see: > ><http://sourceware.org/automake/automake.html#User-Variables>. > Well, the project does not use automake and thus I can not > reasonably use this option. This was only a pointer at good Makefile style: honoring CFLAGS as an user variable, and only that. Something which is expected to be empty unless the users wishes otherwise. > I think one reasonable way would > be to unset CFLAGS for cdbs (well, CFLAGS_<package>="" is in > fact not unsetting it, because it just get's a new value but > it is defined and overrides the upstream setting) and use > a MYCFLAGS instead that I can append to the upstream CFLAGS > later on when needed. Unfortunately I have not found a way > to prevent cdbs from defining CFLAGS. It's really not cdbs' fault, but an upstream design issue of the Makefile you're trying to use. > Moreover I'm really amazed that there is no way force replacement > of CFLAGS inside a Makefile once it is setted outside. I would > call this an insane constraint of make. There is, try "override" -- but just to see how it works. :) -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]