| 1 |
On Wednesday 07 June 2006 11:13, Brian Harring wrote: |
| 2 |
> Resurrecting this issue (yet another round) since FEATURES=debug-build |
| 3 |
> was shoved in... |
| 4 |
|
| 5 |
yes, i forced the issue after requesting feedback several times and getting no |
| 6 |
further blocking input |
| 7 |
|
| 8 |
> 1) flip on nostrip in the restrict. |
| 9 |
> |
| 10 |
> For #1, use conditional support was added to portage somewhere around |
| 11 |
> 2.0.51_pre18; support is still there, so you can use |
| 12 |
> RESTRICT="debug-build? ( nostrip )" now. |
| 13 |
|
| 14 |
FEATURES=debug-build already takes care of the nostrip/splitdebug logic ... |
| 15 |
you'd rather have us add that one conditional line to every ebuild ? |
| 16 |
|
| 17 |
> 2) adjust CX*FLAGS, LDFLAGS |
| 18 |
> |
| 19 |
> As for #2, we already have eclasses mangling flags, this is no |
| 20 |
> different. |
| 21 |
|
| 22 |
sure it is ... again, you'd have us utilize the eclass in every single package |
| 23 |
instead of having a sane default via portage for everything ? |
| 24 |
|
| 25 |
> Two approaches to this- |
| 26 |
> 1) FEATURES="debug-build". |
| 27 |
> pros: |
| 28 |
> 1) doesn't require modifying anything in the tree. |
| 29 |
|
| 30 |
everyone gets it for free |
| 31 |
|
| 32 |
> cons: |
| 33 |
> 1) no way to know if the feature will actually affect a pkg (won't |
| 34 |
> do jack to a pure python/perl/shell/ruby pkg, no point in even |
| 35 |
> trying) |
| 36 |
|
| 37 |
true, but do you really expect debug output from shell scripts |
| 38 |
|
| 39 |
> 2) FEATURES are not controllable via any package.* file. |
| 40 |
|
| 41 |
only because the portage guys have refused to implement what many people have |
| 42 |
requested over and over, telling them to use bashrc hacks instead |
| 43 |
|
| 44 |
> 3) pkgs that support debug builds, but are not affected by trying to |
| 45 |
> set a default set of *FLAGS have to now go and check FEATURES to |
| 46 |
> discern if they should produce a debug build. |
| 47 |
|
| 48 |
like what ? whether you're checking USE or FEATURES, it's the same thing |
| 49 |
|
| 50 |
> 4) no way to make the debug-build option associative to deps; simple |
| 51 |
> example, consider mysql python bindings. Debug info there quite |
| 52 |
> likely isn't all that useful for a segfault- if the horkage occurs |
| 53 |
> in mysql, you just get the usual ?? backtrace, and wind up having |
| 54 |
> to take a second manual step of rebuilding mysql with debug |
| 55 |
> enabled. |
| 56 |
|
| 57 |
how is this specific to using FEATURES ? you have to manually rebuild the |
| 58 |
deps whether you use USE or FEATURES |
| 59 |
|
| 60 |
> 5) cannot control the setting per package. |
| 61 |
|
| 62 |
way to duplicate (2) so that the cons list would be bigger than your pro list |
| 63 |
below |
| 64 |
|
| 65 |
> 2) USE="debug-build" |
| 66 |
> pros: |
| 67 |
> 1) it's explicit. if the package can generate a debug-build version |
| 68 |
> of itself, you see the debug-build flag in it's IUSE. |
| 69 |
|
| 70 |
true |
| 71 |
|
| 72 |
> 2) appropriate designed eclass, ebuild can specify up front any |
| 73 |
> nonstandard *flags additions that should be made- for example, |
| 74 |
> ciaran's suggestion to mangle CXXFLAGS when dealing with STL so |
| 75 |
> that the result is useful. |
| 76 |
|
| 77 |
the flags ciaran suggested would be useful for all of C++, regardless of STL |
| 78 |
|
| 79 |
> Possible via FEATURES, but ebuild would |
| 80 |
> have to test features for it (something it should be mostly unaware |
| 81 |
> of, features are mainly pkg manager directives, not ebuild). |
| 82 |
|
| 83 |
i dont get it ... are you arguing for FEATURES=debug-build or USE=debug-build |
| 84 |
here ? |
| 85 |
|
| 86 |
> 3) via use deps, it's possible to address 1.4 from above- |
| 87 |
> python-mysql can just slip in a |
| 88 |
> "debug-build? ( dev-db/mysql[debug-build] )", one less manual step |
| 89 |
> required. |
| 90 |
|
| 91 |
sounds like you're duplicating the work of RDEPEND split that people have |
| 92 |
already decided on doing |
| 93 |
|
| 94 |
> 4) use flags can be controlled per package via package.use; you can |
| 95 |
> force $YOUR_PERSONAL_PROJECT to always be built with debug symbols |
| 96 |
> cleanly. |
| 97 |
|
| 98 |
which is a moot point once portage peeps actually implement a package.env |
| 99 |
|
| 100 |
> cons: |
| 101 |
> 1) requires modifying the tree, and introduction of eclass for it. |
| 102 |
|
| 103 |
this is a *huge* con ... developers are lazy, *i'm* lazy ... i certainly do |
| 104 |
not want to go through every single package i maintain and add 'debug-build' |
| 105 |
to IUSE or 'inherit some-new-eclass' |
| 106 |
|
| 107 |
if the large majority of packages are going to be taking advantage of a |
| 108 |
feature, isnt the logical thing to opt everyone in rather than forcing the |
| 109 |
majority to opt themselves in ? |
| 110 |
|
| 111 |
> 2) existing USE="debug" (namely nano) is used to enable runtime |
| 112 |
> changes, asserts, etc; would have two sets of flags, debug-build |
| 113 |
> and runtime changes (debug flag). |
| 114 |
|
| 115 |
how is this a con ? you provide no way of letting this useful runtime debug |
| 116 |
code from being enabled |
| 117 |
-mike |
Archives