Re: [PATCH v5 01/18] Makefile: pass CPPFLAGS through to fllow customization

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:

quoted

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@thewrittenword.com)