Bug#578597: Recommend usage of dpkg-buildflags to initialize CFLAGS and al.
Hi,
Raphael Hertzog wrote:
> 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.
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?
[...]
> 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.
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
Reply to: