Hi Robin, On Fri, May 14, 2010 at 09:53:30AM +0000, Robin H. Johnson wrote: > On Fri, May 14, 2010 at 09:31:32AM +0000, Gary V. Vaughan wrote: > > Without this patch there is no straight forward way to pass additional > > CPPFLAGS at configure-time. At TWW, everything non-vendor package is > > installed to its own subdirectory, so we need the following to show > > the preprocessor where the headers for the libraries we will link > > later can be found: > As a point of comparision, this is what we use in Gentoo, to allow us to > override many of the variables: > sed -i \ > -e 's:^\(CFLAGS =\).*$:\1 $(OPTCFLAGS) -Wall:' \ > -e 's:^\(LDFLAGS =\).*$:\1 $(OPTLDFLAGS):' \ > -e 's:^\(CC = \).*$:\1$(OPTCC):' \ > -e 's:^\(AR = \).*$:\1$(OPTAR):' \ > Makefile || die "sed failed" > > Which would be equivilent to changing the Makefile to have: > CFLAGS = $(OPTCFLAGS) -Wall > LDFLAGS = $(OPTLDFLAGS) > CC = $(OPTCC) > AR = $(OPTAR) > > Thereafter, we pass in the relevant values for those variables. > > CPPFLAGS is reserved for flags destined for ONLY the preprocessor, and we don't > want to introduce for that reason. Letting the user pass preprocessor flags to the preprocessor with CPPFLAGS at build and/or configure time is a *very* standard feature. Why would you want to stop a person who builds git from using it? As a matter of fact, Automake even jumps through hoops with AM_CPPFLAGS to make sure that the package maintainer doesn't accidentally trample over the package builder's CPPFLAGS settings - I can't think of a scenario where the person who writes the build system for a package knows more about what CPPFLAGS the person who builds it will need that the person doing the actual building. I'm pretty sure I'm missing the point though, since letting the package builder choose their own CPPFLAGS has been at the core of building Unix packages for as long as I can remember... Cheers, -- Gary V. Vaughan (gary@xxxxxxxxxxxxxxxxxx) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html