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 -- 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/20100421182735.ga23...@progeny.tock
