On Wed, 21 Apr 2010, Jonathan Nieder wrote:
> 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.
Yeah, the goal is to replace those snippets with a call to
dpkg-buildflags.
> 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?
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.
> - Some packages cannot build without optimization [1]. What should
> they do?
CFLAGS = $(shell dpkg-buildflags --get CFLAGS)
CFLAGS += -O2
> - Some packages have been tested to work well with a specific
> optimization preset [2]. How should they specify this?
CFLAGS = $(shell dpkg-buildflags --get CFLAGS)
ifeq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O3
endif
> - Some packages cannot tolerate certain optimizations [3]. Are they
> required 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?
For both of those, I think this is unrelated. The users trying new flags
should certainly expect failures on some packages.
> - Some packages are known to trigger bugs in GCC’s optimizer [4].
> Therefore they should build with optimization. How to declare
> this?
CFLAGS = $(shell dpkg-buildflags --get CFLAGS)
CFLAGS += -O0
> - 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?
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.
> 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.
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,
--
Raphaël Hertzog
Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100422065023.gc24...@rivendell
