Re: Problem with implicit rule for .o files and overriding of CXXFLAGS.

[Yavor Doganov <yavor@gnu.org>]

At Sun, 29 Jun 2008 20:03:51 +0900,
Charles Plessy wrote:
> 
> > I don't know; this text still makes me feel uneasy.
> 
> how about :
> 
> When a Debian binary package is built, environment variables such as
> {{{CFLAGS}}} and {{{CXXFLAGS}}} are set by {{{dpkg-buildpackage}}}
> and may override the corresponding variables in the
> {{{Makefile}}}. 

Much better, but it doesn't happen with `proda' (namely because
CXXFLAGS is defined there) and perhaps lots of other packages:

$ export CXXFLAGS="-Wextra -Werror -O3"
$ make
g++ -g -W -Wall -pedantic -DVERSION="\"1.00\""   -c -o AlignedFragment.o AlignedFragment.cc
[...]

For the typical autoconfiscated package, variables as set by
`dpkg-buildpackage' will propagate, since ./configure will pick them
up from the environment.

But...  many packages already define conditionally at least
CFLAGS/CXXFLAGS in debian/rules to cater for `noopt' (and `nostrip'
when not handled automatically by `dh_strip').  For LDGFLAGS, many
packages pass `-Wl,--as-needed' at least.  So it is wrong to rely on
dpkg-buildpackage for doing the right thing (which partly explains why
"only" 20-40 RC bugs popped up when this functionality was introduced)
-- the maintainer must be aware of this behaviour, but it is far from
sufficient to ensure that the package in question is policy compliant.

The matter is more complex in general; add here the well known fact
that a truckload of upstream makefiles/build systems is broken.