Bug#578597: Recommend usage of dpkg-buildflags to initialize CFLAGS and al.
On Thu, Apr 22, 2010 at 08:46:50AM +0200, Goswin von Brederlow wrote:
> Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> writes:
> > On Wed, Apr 21, 2010 at 09:10:54AM +0200, Raphael Hertzog wrote:
> >> Package: debian-policy
> >> Severity: wishlist
> >> The desired outcome is that all package grab the values directly from
> >> dpkg-buildflags and that we can stop exporting the variables from
> >> dpkg-buildpackage. That way calling debian/rules directly and via
> >> dpkg-buildpackage should give the same result.
> >> Please modify the policy to recommend the usage of dpkg-buildflags (I would
> >> suggest to push that policy change just at the start of squeeze+1).
> >> CFLAGS=$(shell dpkg-buildflags --get CFLAGS)
> > There should be some documentation about how thoses variables should be used,
> > whether they should replace or augment the value set by debian/rules, before or
> > after the upstream makefile change, etc...
> > Currently it is impossible to use them at all in a reliable way.
> > For example suppose debian/rules do
> > CFLAGS="-O2 -Wall -g"
> > and upstream configure do
> > CFLAGS="$CFLAGS -fno-strict-aliasing"
> > before writing the Makefile so C files are built with
> > gcc -O2 -Wall -g -fno-strict-aliasing foo.c
> > Suppose user set CFLAGS to XXX. How C files should build ?
> > gcc XXX foo.c
> > gcc XXX -fno-strict-aliasing foo.c
> > gcc XXX -O2 -Wall -g -fno-strict-aliasing foo.c
> > gcc XXX -g -fno-strict-aliasing foo.c
> User knows best and if configure just adds things to CFLAGS then that
> can't be avoided in rules. So you should get:
Of course it can, it just need to do
instead of make to override the CFLAGS.
> gcc XXX -fno-strict-aliasing foo.c
What happen if debian/rules is doing
dh_strip -a --dbg-package=foo-dbg
Imagine a large red swirl here.