waf vs enrionment CPPFLAGS and LDFLAGS

[Jeremy Allison]

On Mon, Oct 27, 2014 at 06:25:28PM +0100, Ralph Böhme wrote:
> Hi all,
> 
> I think I've come across a behaviour in waf which I'd consider a bug [1]:
> 
> when building the C compiler invocation for compiling or linking, waf
> places the environment varialbles CPPFLAGS and LDFLAGS *before* all
> internal flags computed at the configuration stage.
> 
> The templates come from buildtools/wafadmin/Tools/cc.py:
> 
> cc_str = '${CC} ${CCFLAGS} ${CPPFLAGS} ${_CCINCFLAGS} ${_CCDEFFLAGS} ${CC_SRC_F}${SRC} ${CC_TGT_F}${TGT}'
> link_str = '${LINK_CC} ${CCLNK_SRC_F}${SRC} ${CCLNK_TGT_F}${TGT[0].abspath(env)} ${LINKFLAGS}'
> 
> As a result, a Samba build will erroneously pick up headers or
> libraries from the paths specified in the environment variables, no
> matter what the waf build script intention is.
> 
> This manifested in a broken build of Samba 4.1.12 with Macport on OS
> X. Macports passed CPPFLAGS=-I/some/path to waf configure where in
> /some/path happened to exist GSSAPI headers. The internal heimdal
> build then picked up those headers instead of the internal copies,
> because -I/some/path was put infront of the internal include.
> 
> Note that this is NOT specifically related to our GSSAPI/Heimdal
> build, it's a general waf bug. The immediate fix is:
> 
> <http://git.samba.org/?p=slow/samba.git;a=commitdiff;h=2429a9f65c0da893c5e843fa52568a913b388bfc>
> 
> Fwiw, this bug is still present in upstream waf.

Ralph, have you submitted this upstream ?

I suggest you do so, and once done we'll just
fix it locally until we can re-sync with an
upstream release.

Cheers,

	Jeremy.