Package: debian-policy
Severity: wishlist

With dpkg 1.15.7 just uploaded to sid, there's now a dpkg-buildflags
command that should be used to initialize CFLAGS, LDFLAGS, CPPFLAGS,
FFLAGS, CXXFLAGS. It offers some flexibility for the local admin and for
the user to override/extend the default flags used during a package
compilation.

dpkg-buildpackage continues to export them to not break packages but it
exports the value returned by dpkg-buildflags.

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)

Note: by using this tool you automatically implement the "noopt" feature
of DEB_BUILD_OPTIONS.

Cheers,

Hi,

Raphael Hertzog wrote:

Neat tool; thanks for writing it.

Even without the support of policy, policy already indicates an
obvious reason to use this tool: supporting noopt.

On the other hand, many packages already support the noopt option,
usually with code like the following:

 ifeq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
   CFLAGS = -g -O2
 else
   CFLAGS = -g -O0
 endif

In particular, they override any value of CFLAGS set through the
environment already.

Given that it will probably be a while before this tool is used
universally, what benefit does an existing package with code like the
above get from switching to using dpkg-buildflags?

[...]

In the most common case, yes, this is true.

For this to become policy, I think we’d need to figure out the edge
cases:

 - Some packages cannot build without optimization [1].  What should
   they do?

 - Some packages have been tested to work well with a specific
   optimization preset [2].  How should they specify this?

 - Some packages cannot tolerate certain optimizations [3].  Are they
   required to declare this?

 - Some packages are known to trigger bugs in GCC’s optimizer [4].
   Therefore they should build with optimization.  How to declare
   this?

 - Some build systems do not tolerate warnings (because they check
   stderr or because they use -Werror).  Some compiler flags add
   warnings.  Is this a bug, and should policy mandate any
   preventative measures?

 - Some packages depend on a GCC version older than the current
   default, which might not support all the options that were chosen
   on a system.  Bug?

In the short term, I would be more inclined to see this recommended
through the developer’s reference so we can get some experience
working with it.

Just my two cents,
Jonathan

[1] http://sourceware.org/ml/libc-hacker/2007-10/msg00023.html
[2] zlib uses -O3.
[3] I don’t know if it’s still true, but at some point Qt could
not tolerate strict aliasing.
[4] http://bugs.debian.org/427907

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

Should it depends of some properties of the package, if yes which ?

Cheers,

Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> writes:

User knows best and if configure just adds things to CFLAGS then that
can't be avoided in rules. So you should get:

gcc XXX -fno-strict-aliasing foo.c

% DEB_CFLAGS_SET=-O0 dpkg-buildflags --get CFLAGS
-O0
% DEB_CFLAGS_APPEND=-Werror dpkg-buildflags --get CFLAGS
-g -O2 -Werror

Maybe setting CFLAGS should behave just like setting DEB_CFLAGS_SET. But
currently that is ignored. Might be a good thing because now you can set
CFLAGS for non-debian sources without interfering with building debian
packages.

MfG
        Goswin

PS: Why can't I do 'eval $(shell dpkg-buildflags --all)'?

Yeah, the goal is to replace those snippets with a call to
dpkg-buildflags.

It will allow users of source packages to experiment more easily with
alternate flags (hardening, -Wall -Werror, etc.).

Note in the answers below all my answers are sample, I'm sure there are
other ways to achieve the same but it was meant to provide a starting
point.

CFLAGS = $(shell dpkg-buildflags --get CFLAGS)
CFLAGS += -O2

CFLAGS = $(shell dpkg-buildflags --get CFLAGS)
ifeq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
    CFLAGS += -O3
endif

For both of those, I think this is unrelated. The users trying new flags
should certainly expect failures on some packages.

CFLAGS = $(shell dpkg-buildflags --get CFLAGS)
CFLAGS += -O0

Huh? I'm fairly sure we're going to be very conservative with the flags
enabled by default on dpkg-buildflags. And in the unlikely case
where this happens, the package maintainer can do a substitution to remove
the offending option if really needed.

While we certainly need experience, I think the policy is the right place
for documenting this interface. We want an unified interface to control
build flags and the policy is what we use to ensure coherence between
all our packages.

Cheers,

Have you read the dpkg-buildflags manual page? If the user wants to modify
CFLAGS he doesn't set it manually but he uses one of the facility to
extend/override it. The result returned by dpkg-buildflags is supposed to
give the full CFLAGS.

So in your list:

Is the right one given XXX=$(shell dpkg-buildflags --get CFLAGS).

Cheers,

Of course it can, it just need to do
make "CFLAGS=$XXX"
instead of make to override the CFLAGS.

What happen if debian/rules is doing
dh_strip -a --dbg-package=foo-dbg

Cheers,

Raphael Hertzog wrote:
[...]

With this caveat the idea makes more sense to me.  Thanks for the
explanation.

Jonathan

Yes, calling debian/rules directly or using dpkg-buildpackage
having the same result is clearly the behaviour we want, which is
something we don't have now.  dpkg-buildflags should be used by
packages just like dpkg-architecture.  So I'm in favour of
recommending it.


Kurt

        Hey

 Great to this see effort!

 I wonder why would we ever want to remove the exports?  To prevent
 accidental pickup of *FLAGS from the env?

 Would it make sense to recommend:
    CFLAGS ?= $(shell dpkg-buildflags --get CFLAGS)
 instead?

 Or perhaps:
    DEB_CFLAGS_SET ?= $(shell dpkg-buildflags --get CFLAGS)
    [...]
    ./configure CFLAGS="$(DEB_CFLAGS_SET)"

 I see that's not in the man page, not sure it would make sense in
 policy either.

    Thanks

Hi,

Because they will be useless and induce different behaviour between a raw
debian/rules call and dpkg-buildpackage.

IMO no, because we don't want to pickup a value from the environment. If
the user want to alter the flags used by the current build, he should use
the interface offered by dpkg-buildflags (i.e. DEB_CFLAGS_SET/APPEND).

This definitely not, DEB_CFLAGS_SET is for the user not for the maintainer.

Cheers,

Agreed on all points.

THIS & MY iPhone Charles Groothoff