[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Override CFLAGS when using cdbs



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



Reply to: