Gentoo Archives: gentoo-dev

From: Maciej Mrozowski <reavertm@××××××.fm>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] debug/release builds extensions/clarification proposal
Date: Mon, 01 Dec 2008 05:16:28
1 Hi
3 I would like to give some idea into consideration.
5 Abstract
6 In short, adding following new variables to make.conf and implement handling
7 of them in eclasses:
8 - CFLAGS_DEBUG (and friends like CXXFLAGS_DEBUG) - use defined debug compiler
9 flags - by default set to -O0 -ggdb (and maybe -Wall as well)
10 - LDFLAGS_DEBUG - user defined debug linker flags - default to "${LDFLAGS}"
11 - FEATURES_DEBUG - default to "${FEATURES} nostrip" (or splidebug, according
12 to preference)
14 Background
15 Currently handling debug/release builds is incoherent and misleading to say
16 the least. We have got in Gentoo:
17 - CFLAGS/LDFLAGS - user needs to take care of adding -O0 and/or -ggdb
18 - user needs to take care of FEATURES=nostrip or FEATURES=splitdebug (not
19 both)
20 - user may set debug USE flag
22 The drawbacks are as follows:
23 - USE=debug is useless when CFLAGS/LDFLAGS or FEATURES are not appropriate
24 - CFLAGS/LDFLAGS must be set globally when they are about to be "supported"
25 - those who don't want to set them globally, they are forced to use (very
26 flexible and great indeed) /etc/portage/env hack - which is undocumented and
27 unsupported, because everything user set there, is not shown by emerge --info,
28 thus bug reports from such machines are not taken into consideration, as
29 virtually everything that breaks can be there
30 - too much choice leads to confusion, and many users who enabled some of those
31 (but not all), still don't get useful backtraces and only fool themselves when
32 reporting something upstream.
34 Motivation:
35 The idea is modeled after handling such situations in CMake build system. I'm
36 one of contributors to official Gentoo KDE team experimental overlay (kde-
37 crazy) and we provide live ebuilds and betas/snapshots for KDE4 and related
38 applications. It's quite probable that many of our users participate in KDE
39 testing, it's vital to provide for them an easy way of setting up testing box
40 (though it's not the motive here).
41 KDE4 uses CMake as build system and CMake out-of-the-box provides build
42 configurations: Release, Debug, RelWithDebInfo, MinSizeRel (one can easily
43 figure out what they mean). For typical use, user doesn't want nor needs more
44 than two configurations - let's call them Release and Debug - it fits in
45 existing USE=debug handling scheme, where there are two build types with
46 "release" as default. Overlay team and Gentoo KDE developers already make use
47 of this feature and we provide debug USE flag for all KDE4 packages. The
48 motive is to make handling build type in more coherent, predictable and less
49 confusing way and I guess this proposal addresses it quite well.
51 Implementation:
52 Implementation would be provided by build system eclasses - for far cmake
53 eclasses could benefit from this extension, though new USE=debug capable
54 eclass could be introduced for other build systems (including autotools).
55 Implementation is trivial - eclass would be responsible for handling USE=debug
56 flag, when debug is set:
57 - replace CFLAGS with CFLAGS_DEBUG, LDFLAGS with LDFLAGS_DEBUG and possibly
58 others
60 Implementation could as well automatically add "debug" to IUSE as well -
61 specific packages that are not interested in such flag - would just override
62 IUSE in its ebuilds.
63 For cmake-utils - handling debug IUSE is already done, only replacing
64 CFLAGS/LDFLAGS/FEATURES would be requited.
65 For autoconf based packages - some of them already provide 'support' for debug
66 builds ('a'ka --enable-debug), but making use of debug USE would need special
67 support here or separate eclass that could be introduced for packages that can
68 benefit. If could be as well enforced globally (by adding either --enable-
69 debug or --disable-debug apart from switching CFLAGS - as confgiure scipt
70 ignores unknown arguments) but that's just a matter or implementation.
72 Backward compatibility
73 As extension operates on newly introduced variables - backward compatibility
74 is preserved. Backward compatibility may be "broken" for those who utilize
75 /etc/portage/env hack as strange compiler/iinker flag/FEATURE combinations may
76 appear.
78 In similar scheme more build profiles could be implemented, (like libs/apps
79 ready for profiling) but let's leave it alone for now.
81 Discussion and constructive criticism is welcome :)
83 --
84 regards
85 MM


File name MIME type
signature.asc application/pgp-signature