Hi
I would like to give some idea into consideration.
Abstract
In short, adding following new variables to make.conf and implement handling
of them in eclasses:
- CFLAGS_DEBUG (and friends like CXXFLAGS_DEBUG) - use defined debug compiler
flags - by default set to -O0 -ggdb (and maybe -Wall as well)
- LDFLAGS_DEBUG - user defined debug linker flags - default to ${LDFLAGS}
- FEATURES_DEBUG - default to ${FEATURES} nostrip (or splidebug, according
to preference)
Background
Currently handling debug/release builds is incoherent and misleading to say
the least. We have got in Gentoo:
- CFLAGS/LDFLAGS - user needs to take care of adding -O0 and/or -ggdb
- user needs to take care of FEATURES=nostrip or FEATURES=splitdebug (not
both)
- user may set debug USE flag
The drawbacks are as follows:
- USE=debug is useless when CFLAGS/LDFLAGS or FEATURES are not appropriate
- CFLAGS/LDFLAGS must be set globally when they are about to be supported
- those who don't want to set them globally, they are forced to use (very
flexible and great indeed) /etc/portage/env hack - which is undocumented and
unsupported, because everything user set there, is not shown by emerge --info,
thus bug reports from such machines are not taken into consideration, as
virtually everything that breaks can be there
- too much choice leads to confusion, and many users who enabled some of those
(but not all), still don't get useful backtraces and only fool themselves when
reporting something upstream.
Motivation:
The idea is modeled after handling such situations in CMake build system. I'm
one of contributors to official Gentoo KDE team experimental overlay (kde-
crazy) and we provide live ebuilds and betas/snapshots for KDE4 and related
applications. It's quite probable that many of our users participate in KDE
testing, it's vital to provide for them an easy way of setting up testing box
(though it's not the motive here).
KDE4 uses CMake as build system and CMake out-of-the-box provides build
configurations: Release, Debug, RelWithDebInfo, MinSizeRel (one can easily
figure out what they mean). For typical use, user doesn't want nor needs more
than two configurations - let's call them Release and Debug - it fits in
existing USE=debug handling scheme, where there are two build types with
release as default. Overlay team and Gentoo KDE developers already make use
of this feature and we provide debug USE flag for all KDE4 packages. The
motive is to make handling build type in more coherent, predictable and less
confusing way and I guess this proposal addresses it quite well.
Implementation:
Implementation would be provided by build system eclasses - for far cmake
eclasses could benefit from this extension, though new USE=debug capable
eclass could be introduced for other build systems (including autotools).
Implementation is trivial - eclass would be responsible for handling USE=debug
flag, when debug is set:
- replace CFLAGS with CFLAGS_DEBUG, LDFLAGS with LDFLAGS_DEBUG and possibly
others
- replace FEATURES with FEATURES_DEBUG
Implementation could as well automatically add debug to IUSE as well -
specific packages that are not interested in such flag - would just override
IUSE in its ebuilds.
For cmake-utils - handling debug IUSE is already done, only replacing
CFLAGS/LDFLAGS/FEATURES would be requited.
For autoconf based packages - some of them already provide 'support' for debug
builds ('a'ka --enable-debug), but making use of debug USE would need special
support here or separate eclass that could be introduced for packages that can
benefit. If could be as well enforced globally (by adding either --enable-
debug or --disable-debug apart from switching CFLAGS - as confgiure scipt
ignores unknown arguments) but that's just a matter or implementation.
Backward compatibility
As extension operates on newly introduced variables - backward compatibility
is preserved. Backward compatibility may be broken for those who utilize
/etc/portage/env hack as strange compiler/iinker flag/FEATURE combinations may
appear.
In similar scheme more build profiles could be implemented, (like libs/apps
ready for profiling) but let's leave it alone for now.
Discussion and constructive criticism is welcome :)
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
