On Wednesday 07 June 2006 11:13, Brian Harring wrote: > Resurrecting this issue (yet another round) since FEATURES=debug-build > was shoved in...
yes, i forced the issue after requesting feedback several times and getting no further blocking input > 1) flip on nostrip in the restrict. > > 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. FEATURES=debug-build already takes care of the nostrip/splitdebug logic ... you'd rather have us add that one conditional line to every ebuild ? > 2) adjust CX*FLAGS, LDFLAGS > > As for #2, we already have eclasses mangling flags, this is no > different. sure it is ... again, you'd have us utilize the eclass in every single package instead of having a sane default via portage for everything ? > Two approaches to this- > 1) FEATURES="debug-build". > pros: > 1) doesn't require modifying anything in the tree. everyone gets it for free > 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) true, but do you really expect debug output from shell scripts > 2) FEATURES are not controllable via any package.* file. only because the portage guys have refused to implement what many people have requested over and over, telling them to use bashrc hacks instead > 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. like what ? whether you're checking USE or FEATURES, it's the same thing > 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. how is this specific to using FEATURES ? you have to manually rebuild the deps whether you use USE or FEATURES > 5) cannot control the setting per package. way to duplicate (2) so that the cons list would be bigger than your pro list below > 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. true > 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. the flags ciaran suggested would be useful for all of C++, regardless of STL > 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). i dont get it ... are you arguing for FEATURES=debug-build or USE=debug-build here ? > 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. sounds like you're duplicating the work of RDEPEND split that people have already decided on doing > 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. which is a moot point once portage peeps actually implement a package.env > cons: > 1) requires modifying the tree, and introduction of eclass for it. this is a *huge* con ... developers are lazy, *i'm* lazy ... i certainly do not want to go through every single package i maintain and add 'debug-build' to IUSE or 'inherit some-new-eclass' if the large majority of packages are going to be taking advantage of a feature, isnt the logical thing to opt everyone in rather than forcing the majority to opt themselves in ? > 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). how is this a con ? you provide no way of letting this useful runtime debug code from being enabled -mike
pgpEodlK3Q9Gd.pgp
Description: PGP signature
