Hi Robin, On Fri, May 14, 2010 at 11:04:59AM +0000, Robin H. Johnson wrote: > On Fri, May 14, 2010 at 10:58:32AM +0000, Gary V. Vaughan wrote: > > 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. > AM_CFLAGS != AM_CPPFLAGS. My concern was the mixing of them. While I agree that mixing up AM_CFLAGS and AM_CPPFLAGS, or even AM_CXXFLAGS and AM_CFLAGS is likely to break your build, that's no reason to deprecate the user's CPPFLAGS setting! > As a middle ground: > CFLAGS = $(OPTCFLAGS) -Wall > CPPFLAGS = $(OPTCPPFLAGS) > LDFLAGS = $(OPTLDFLAGS) > CC = $(OPTCC) > AR = $(OPTAR) Okay, I think we are mostly in agreement here. In all the packages we build here at TWW, we let the user use CFLAGS, CPPFLAGS, LDFLAGS etc, and to preserve that we'll jump through some Automake-like hoops so that the build system doesn't overwrite them at build time. You actually propose the same separation, except that you want the package builder to use the OPTCFLAGS, OPTCPPFLAGS, OPTLDFLAGS etc so that the build system can use CFLAGS et al. I don't think this buys you anything but confusion when anyone used to building on Unix over the last 20 or 30 years tries to pass flags into the build using the tried and tested mechanism (CFLAGS, CPPFLAGS et al) to no effect. Git already follows the tried and tested mechanism, but forgot to honor the user's CPPFLAGS setting, which is what this patch is trying to address. 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