1 |
Hi |
2 |
|
3 |
I would like to give some idea into consideration. |
4 |
|
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) |
13 |
|
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 |
21 |
|
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. |
33 |
|
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. |
50 |
|
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 |
59 |
- replace FEATURES with FEATURES_DEBUG |
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. |
71 |
|
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. |
77 |
|
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. |
80 |
|
81 |
Discussion and constructive criticism is welcome :) |
82 |
|
83 |
-- |
84 |
regards |
85 |
MM |