[gentoo-dev] fix binary debug support, part elevenity billion + 1

[Brian Harring]

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