Resurrecting this issue (yet another round) since FEATURES=debug-build was shoved in...
Background info- http://thread.gmane.org/gmane.linux.gentoo.devel/35202/focus=35212 Quick summary, there needs to be an easy way to flag on essentially "leave the symbols intact/don't mangle the code too much for this build"; needs a few things- 1) flip on nostrip in the restrict. 2) adjust CX*FLAGS, LDFLAGS For #1, use conditional support was added to portage somewhere around 2.0.51_pre18; support is still there, so you can use RESTRICT="debug-build? ( nostrip )" now. As for #2, we already have eclasses mangling flags, this is no different. Two approaches to this- 1) FEATURES="debug-build". pros: 1) doesn't require modifying anything in the tree. cons: 1) no way to know if the feature will actually affect a pkg (won't do jack to a pure python/perl/shell/ruby pkg, no point in even trying) 2) FEATURES are not controllable via any package.* file. 3) pkgs that support debug builds, but are not affected by trying to set a default set of *FLAGS have to now go and check FEATURES to discern if they should produce a debug build. 4) no way to make the debug-build option associative to deps; simple example, consider mysql python bindings. Debug info there quite likely isn't all that useful for a segfault- if the horkage occurs in mysql, you just get the usual ?? backtrace, and wind up having to take a second manual step of rebuilding mysql with debug enabled. 5) cannot control the setting per package. 2) USE="debug-build" pros: 1) it's explicit. if the package can generate a debug-build version of itself, you see the debug-build flag in it's IUSE. 2) appropriate designed eclass, ebuild can specify up front any nonstandard *flags additions that should be made- for example, ciaran's suggestion to mangle CXXFLAGS when dealing with STL so that the result is useful. Possible via FEATURES, but ebuild would have to test features for it (something it should be mostly unaware of, features are mainly pkg manager directives, not ebuild). 3) via use deps, it's possible to address 1.4 from above- python-mysql can just slip in a "debug-build? ( dev-db/mysql[debug-build] )", one less manual step required. 4) use flags can be controlled per package via package.use; you can force $YOUR_PERSONAL_PROJECT to always be built with debug symbols cleanly. cons: 1) requires modifying the tree, and introduction of eclass for it. 2) existing USE="debug" (namely nano) is used to enable runtime changes, asserts, etc; would have two sets of flags, debug-build and runtime changes (debug flag). Now... not to hard to figure out from above which route I prefer, but that *should* be an accurate pro/con of the two routes for this. Note also that common pros/cons are exempted; fex, ability to specify via profile default debug *flags. So... kindly state which you view as best. Thoughts? ~harring
pgpDUQR0mmJHi.pgp
Description: PGP signature
