portage's ability to emerge packages with debugging code enabled has always
been a mess. from random env vars to USE flags to FEATURES keywords, portage
has always been inconsistent
the situation has finally settled down around the USE flag 'debug'. this,
however, is used in two (very different) ways. some developers assume this
means that CFLAGS and CXXFLAGS should be forced to '-g' (or something along
those lines) and that the ebuild should enforce RESTRICT=nostrip which
eventually gave rise to the headache known as the debug eclass. other
developers assume that the USE flag should only be used to enable internal
debug routines (if) a package supports it (for example, a library would
include a lot of verbose output while it's being run), or to enable profiling
features (ruh roh!).
so, might we finally settle on this ? here's a solution i think would make
everyone happy:
- get rid of debug.elcass (having every single ebuild 'inherit debug' is ugly)
- USE=debug will force portage to:
- auto append nostrip to either FEATURES/RESTRICT, doesnt matter
- export CFLAGS=${CFLAGS_DEBUG:--g -gdb -pipe}
- export CXXFLAGS=${CXXFLAGS_DEBUG:--g -gdb}
- stop using 'debug' in ebuilds unless a package wants to add more crap to
CFLAGS for debugging purposes
- create a new USE flag, debuginc, which turns on internal debugging routines
(the meaning of this of course varies between packages)
- switch to using the existing 'profile' USE flag for profiling generation
-mike
--
[email protected] mailing list
