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

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

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 3091 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 4465 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

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

[Zac Medico]

[-- Attachment #1: Type: text/plain, Size: 1646 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Frysinger wrote:
> On Wednesday 07 June 2006 11:13, Brian Harring wrote:
>>   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'

Sometimes it takes a little extra work to do things right, but hopefully it will pay off in the long run.  A poor design decision made now can haunt us for years to come.

> 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 ?

It really depends on the pros/cons applying something on a *global* scale, like you propose.  A package manager (such as portage) will never be able to make debug-build decisions that work well for *every* ebuild.  That's why it's better for ebuilds to make those decisions themselves (with the help of eclasses).

Sure, it will take some work to make those changes to ebuilds, but it will be worth the effort in the long run.  I've attached a script that you can use for /etc/portage/bashrc that provides the same functionality as your debug-build feature.  You can use it as an interim solution until  USE=debug-build support has been added to all of the ebuilds that would benefit from it.

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEhxtN/ejvha5XGaMRAlRuAJ0Q0/p6Tq1k/+N3ejzScYsAe8TgvgCg3Wym
EpgniVng6MItb8uxtJLk5Ac=
=2nT/
-----END PGP SIGNATURE-----

[-- Attachment #2: debug-build.bashrc --]
[-- Type: text/plain, Size: 395 bytes --]

#!/usr/bin/env bash

hasq() {
	[[ " ${*:2} " == *" $1 "* ]]
}

if hasq debug-build ${USE}; then
	[ -z "${DEBUG_CFLAGS}" ] && export DEBUG_CFLAGS="-g -O"
	[ -z "${DEBUG_CXXFLAGS}" ] && export DEBUG_CXXFLAGS="${DEBUG_CFLAGS}"
	for x in CFLAGS CXXFLAGS LDFLAGS; do
		eval "export ${x}=\"\${DEBUG_${x}}\""
	done
	if ! hasq splitdebug ${FEATURES}; then
		export FEATURES="${FEATURES} nostrip"
	fi
fi

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

[Grant Goodyear]

[-- Attachment #1: Type: text/plain, Size: 2362 bytes --]

Zac Medico wrote: [Wed Jun 07 2006, 01:30:38PM CDT]
> Mike Frysinger wrote:
> > 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'
> 
> Sometimes it takes a little extra work to do things right, but
> hopefully it will pay off in the long run.  A poor design decision
> made now can haunt us for years to come.

A "little extra work"?  I'm pretty sure that such an eclass would be
required for better than half the tree (every package that contains some
C or C++).  If almost everybody has to add the same piece of
boilerplate to their ebuilds, then perhaps a sane package manager should
be able to figure out what to do without the boilerplate.  That
rationale seems especially true in this case, where nostrip and
debugging flags will do no harm for packages that aren't C or C++.

> > 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 ?
> 
> It really depends on the pros/cons applying something on a *global*
> scale, like you propose.  A package manager (such as portage) will
> never be able to make debug-build decisions that work well for *every*
> ebuild.  That's why it's better for ebuilds to make those decisions
> themselves (with the help of eclasses).

I would think that your argument would depend on the probability of a
package being an exception to the general rule.  How many packages
actually fail to do what is expected when compiled with -g and nostrip
(noting that those cases without binaries to strip don't count)?
Unless that percentage is significant, then I would think that a simple
solution that handles the common case is a very good thing.

Wouldn't the "simple" solution be to have package.* files that allow the
user to specify FEATURES, CFLAGS, and CXXFLAGS per package?  (Of course,
I do realize that it's the lack of such files that lead vapier to
propose his solution, which is rather more convenient for one-off
builds.)

-g2boojum-
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Alec Warner]

Grant Goodyear wrote:
> Zac Medico wrote: [Wed Jun 07 2006, 01:30:38PM CDT]
> 
>>Mike Frysinger wrote:
>>
>>>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'
>>
>>Sometimes it takes a little extra work to do things right, but
>>hopefully it will pay off in the long run.  A poor design decision
>>made now can haunt us for years to come.
> 
> 
> A "little extra work"?  I'm pretty sure that such an eclass would be
> required for better than half the tree (every package that contains some
> C or C++).  If almost everybody has to add the same piece of
> boilerplate to their ebuilds, then perhaps a sane package manager should
> be able to figure out what to do without the boilerplate.  That
> rationale seems especially true in this case, where nostrip and
> debugging flags will do no harm for packages that aren't C or C++.

I tend to agree here on pragmatic principal as opposed to bowing to 
"this is the ideal case" that some members of the portage team seem to 
want.  debug-build can always be expanded to turn on generic debugging 
for other build systems and languages.

I realize it's not the "perfect solution."  But no one has implemented a 
better one.  People only wait so long for things before getting fed up 
and saying "it's going in anyway."

> 
> 
>>>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 ?
>>
>>It really depends on the pros/cons applying something on a *global*
>>scale, like you propose.  A package manager (such as portage) will
>>never be able to make debug-build decisions that work well for *every*
>>ebuild.  That's why it's better for ebuilds to make those decisions
>>themselves (with the help of eclasses).
> 
> 
> I would think that your argument would depend on the probability of a
> package being an exception to the general rule.  How many packages
> actually fail to do what is expected when compiled with -g and nostrip
> (noting that those cases without binaries to strip don't count)?
> Unless that percentage is significant, then I would think that a simple
> solution that handles the common case is a very good thing.
> 
> Wouldn't the "simple" solution be to have package.* files that allow the
> user to specify FEATURES, CFLAGS, and CXXFLAGS per package?  (Of course,
> I do realize that it's the lack of such files that lead vapier to
> propose his solution, which is rather more convenient for one-off
> builds.)

We've discussed this multiple times, and it's always been the conclusion 
that per package.env should go in bashrc, as bashrc is generally more 
powerful than anything we could devise.  The only downside afaik, for 
bashrc is that you can't do per package FEATURES as FEATURES is a 
python-side var.  But you shouldn't need per package FEATURES by design;
FEATURES are for portage, not your ebuild.

> 
> -g2boojum-

-- 
gentoo-dev@gentoo.org mailing list

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

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Grant Goodyear wrote:
> Zac Medico wrote: [Wed Jun 07 2006, 01:30:38PM CDT]
>> Mike Frysinger wrote:
>>> 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'
>> Sometimes it takes a little extra work to do things right, but
>> hopefully it will pay off in the long run.  A poor design decision
>> made now can haunt us for years to come.
> 
> A "little extra work"?  I'm pretty sure that such an eclass would be
> required for better than half the tree (every package that contains some
> C or C++).  If almost everybody has to add the same piece of
> boilerplate to their ebuilds, then perhaps a sane package manager should
> be able to figure out what to do without the boilerplate.  That

It's a slippery slope when we start to incorporate special cases like that into a generic package manager.  Where does it end?  The same argument could be made again and again to add more special cases that further pollute the package manager.  We already have a standard solution for cases such as this, and that is to share the specialized functionality via an eclass.

> rationale seems especially true in this case, where nostrip and
> debugging flags will do no harm for packages that aren't C or C++.
>>> 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 ?
>> It really depends on the pros/cons applying something on a *global*
>> scale, like you propose.  A package manager (such as portage) will
>> never be able to make debug-build decisions that work well for *every*
>> ebuild.  That's why it's better for ebuilds to make those decisions
>> themselves (with the help of eclasses).
> 
> I would think that your argument would depend on the probability of a
> package being an exception to the general rule.  How many packages
> actually fail to do what is expected when compiled with -g and nostrip
> (noting that those cases without binaries to strip don't count)?
> Unless that percentage is significant, then I would think that a simple
> solution that handles the common case is a very good thing.

Again, it's a slippery slope...

> Wouldn't the "simple" solution be to have package.* files that allow the
> user to specify FEATURES, CFLAGS, and CXXFLAGS per package?  (Of course,
> I do realize that it's the lack of such files that lead vapier to
> propose his solution, which is rather more convenient for one-off
> builds.)

Well, I'd say that per-package environment variables would be a better way to implement per-package CFLAGS, CXXFLAGS, etc.. There is a patch attached to bug 44796 that implements this.  Note that the debug-build.bashrc attached to my last post actually allows per-package debug-build via package.use.

Zac

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEhzK3/ejvha5XGaMRAufAAKDm2l8429xS14uPjbYV7Ky5dlFGHgCggXXH
rBVkHEMCcJZflR13vA26kog=
=DXg0
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alec Warner wrote:
> debug-build can always be expanded to turn on generic debugging
> for other build systems and languages.

Really?  Perhaps you can explain the implementation details a little
more, because it's not obvious to me.  From my perspective a package
level debug-build USE flag models the desired functionality much
better than a package manager level FEATURE.

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEhzdL/ejvha5XGaMRAsKYAJ44xOQPuMNPyhZwSPhb7Y2ywCC5bQCdHHzU
5EKsxkielr/7eyaOp6oOXqk=
=/vtf
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Graham Murray]

Alec Warner <antarus@gentoo.org> writes:

> The only downside afaik, for bashrc is that you can't do per package
> FEATURES as FEATURES is a python-side var.  But you shouldn't need
> per package FEATURES by design; FEATURES are for portage, not your
> ebuild.

>From the perspective of a user, not a developer (though I have been a
programmer for over 25 years), it would sometimes be useful to set
some features on a per package basis rather than globally. These
include binpkg, nostrip, splitdebug and test. 
-- 
gentoo-dev@gentoo.org mailing list

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

[Ned Ludd]

On Wed, 2006-06-07 at 16:05 -0400, Alec Warner wrote:

> We've discussed this multiple times, and it's always been the conclusion 
> that per package.env should go in bashrc, as bashrc is generally more 
> powerful than anything we could devise.  The only downside afaik, for 
> bashrc is that you can't do per package FEATURES as FEATURES is a 
> python-side var.  But you shouldn't need per package FEATURES by design;
> FEATURES are for portage, not your ebuild.


This is a thumbs up? I've got the code sitting in my
$PORTDIR/profiles/base/profile.bashrc to give us just this.
I'd be all to happy to commit it. So that's a yes right? :)


-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

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

[Alec Warner]

Ned Ludd wrote:
> On Wed, 2006-06-07 at 16:05 -0400, Alec Warner wrote:
> 
> 
>>We've discussed this multiple times, and it's always been the conclusion 
>>that per package.env should go in bashrc, as bashrc is generally more 
>>powerful than anything we could devise.  The only downside afaik, for 
>>bashrc is that you can't do per package FEATURES as FEATURES is a 
>>python-side var.  But you shouldn't need per package FEATURES by design;
>>FEATURES are for portage, not your ebuild.
> 
> 
> 
> This is a thumbs up? I've got the code sitting in my
> $PORTDIR/profiles/base/profile.bashrc to give us just this.
> I'd be all to happy to commit it. So that's a yes right? :)
> 
> 

As I told you on IRC, it's not your job to listen to the portage devs on 
  this one, you know what was intended for that support, we've argued 
over it a dozen times.  There is nothing we can do to stop you from 
"mis-using" something in portage, aside from complaining and removing it 
in the next version.  I believe we have made our recommendation and you 
know what we think you should do, but we are not Gentoo.

I would be more concerned with convincing the rest of the developers. 
adding crap in base profile.bashrc will affect 99% of users, so it 
better be friggin correct and useful, otherwise you will piss a ton of 
people off.
-- 
gentoo-dev@gentoo.org mailing list

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 548 bytes --]

On Wednesday 07 June 2006 19:12, Alec Warner wrote:
> I would be more concerned with convincing the rest of the developers.
> adding crap in base profile.bashrc will affect 99% of users, so it
> better be friggin correct and useful, otherwise you will piss a ton of
> people off.

versus the people who are really annoyed that such support hasnt yet been 
integrated into portage proper ?

yes, from the portage side of things, it may be a pita to implement 
per-package env ... but from the user side of things, it's a huge help
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1861 bytes --]

On Wednesday 07 June 2006 16:10, Zac Medico wrote:
> Grant Goodyear wrote:
> > Zac Medico wrote: [Wed Jun 07 2006, 01:30:38PM CDT]
> >> Mike Frysinger wrote:
> >>> 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'
> >>
> >> Sometimes it takes a little extra work to do things right, but
> >> hopefully it will pay off in the long run.  A poor design decision
> >> made now can haunt us for years to come.
> >
> > A "little extra work"?  I'm pretty sure that such an eclass would be
> > required for better than half the tree (every package that contains some
> > C or C++).  If almost everybody has to add the same piece of
> > boilerplate to their ebuilds, then perhaps a sane package manager should
> > be able to figure out what to do without the boilerplate.  That
>
> It's a slippery slope when we start to incorporate special cases like that
> into a generic package manager.  Where does it end?  The same argument 
> could be made again and again to add more special cases that further
> pollute the package manager.  We already have a standard solution for cases
> such as this, and that is to share the specialized functionality via an
> eclass.

the package maintainer provides some sane defaults ... the idea is for the 
full configuration to be offloaded to the profiles

> Well, I'd say that per-package environment variables would be a better way
> to implement per-package CFLAGS, CXXFLAGS, etc.. There is a patch attached
> to bug 44796 that implements this.  Note that the debug-build.bashrc
> attached to my last post actually allows per-package debug-build via
> package.use.

ok ?  so what's stopping it from being integrated ?  people want it ;)
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

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

[Alec Warner]

Mike Frysinger wrote:
> On Wednesday 07 June 2006 19:12, Alec Warner wrote:
> 
>>I would be more concerned with convincing the rest of the developers.
>>adding crap in base profile.bashrc will affect 99% of users, so it
>>better be friggin correct and useful, otherwise you will piss a ton of
>>people off.
> 
> 
> versus the people who are really annoyed that such support hasnt yet been 
> integrated into portage proper ?
> 
> yes, from the portage side of things, it may be a pita to implement 
> per-package env ... but from the user side of things, it's a huge help
> -mike

My e-mail was basically worded as to say "Solar paste your crap to this 
ML."  Is there any reason you need package.env in portage proper as 
opposed to bashrc?
-- 
gentoo-dev@gentoo.org mailing list

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

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Frysinger wrote:
> On Wednesday 07 June 2006 16:10, Zac Medico wrote:
>> Grant Goodyear wrote:
>>> Zac Medico wrote: [Wed Jun 07 2006, 01:30:38PM CDT]
>>>> Mike Frysinger wrote:
>>>>> 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'
>>>> Sometimes it takes a little extra work to do things right, but
>>>> hopefully it will pay off in the long run.  A poor design decision
>>>> made now can haunt us for years to come.
>>> A "little extra work"?  I'm pretty sure that such an eclass would be
>>> required for better than half the tree (every package that contains some
>>> C or C++).  If almost everybody has to add the same piece of
>>> boilerplate to their ebuilds, then perhaps a sane package manager should
>>> be able to figure out what to do without the boilerplate.  That
>> It's a slippery slope when we start to incorporate special cases like that
>> into a generic package manager.  Where does it end?  The same argument 
>> could be made again and again to add more special cases that further
>> pollute the package manager.  We already have a standard solution for cases
>> such as this, and that is to share the specialized functionality via an
>> eclass.
> 
> the package maintainer provides some sane defaults ... the idea is for the 
> full configuration to be offloaded to the profiles
> 
>> Well, I'd say that per-package environment variables would be a better way
>> to implement per-package CFLAGS, CXXFLAGS, etc.. There is a patch attached
>> to bug 44796 that implements this.  Note that the debug-build.bashrc
>> attached to my last post actually allows per-package debug-build via
>> package.use.
> 
> ok ?  so what's stopping it from being integrated ?  people want it ;)

Is this question about per-package env, per-package debug-build, or
both?  In this thread, I've already posted a sample bashrc
implementation of debug-build.  Also, bug 44796 has a comment with a
link to a bashrc implementation of per-package env:

http://article.gmane.org/gmane.linux.gentoo.user/143322

The support already exists in portage for both of these. Either or
both of them can be added to $PORTDIR/profiles/base/profile.bashrc
and every package will inherit the functionality.

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEiAwA/ejvha5XGaMRAlXnAJ9yNx47G/ERA6/VLLH9CmKHOhmUeQCfUqK9
mWIvUdJihBDcXBQT0SsC8j4=
=7d2s
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]

On Thu, 08 Jun 2006 06:49:39 -0400
Alec Warner <antarus@gentoo.org> wrote:

> Mike Frysinger wrote:
> > On Wednesday 07 June 2006 19:12, Alec Warner wrote:
> > 
> >>I would be more concerned with convincing the rest of the
> >>developers. adding crap in base profile.bashrc will affect 99% of
> >>users, so it better be friggin correct and useful, otherwise you
> >>will piss a ton of people off.
> > 
> > 
> > versus the people who are really annoyed that such support hasnt
> > yet been integrated into portage proper ?
> > 
> > yes, from the portage side of things, it may be a pita to implement 
> > per-package env ... but from the user side of things, it's a huge
> > help -mike
> 
> My e-mail was basically worded as to say "Solar paste your crap to
> this ML."  Is there any reason you need package.env in portage proper
> as opposed to bashrc?


I remember portage people asserting before that package.env tricks from
bashrc don't work completely, in that it needs to be in place for
portage.py before the bashrc script is sourced.  Is this no longer a
problem?

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

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

[Ned Ludd]

On Thu, 2006-06-08 at 06:49 -0400, Alec Warner wrote:
> Mike Frysinger wrote:
> > On Wednesday 07 June 2006 19:12, Alec Warner wrote:
> > 
> >>I would be more concerned with convincing the rest of the developers.
> >>adding crap in base profile.bashrc will affect 99% of users, so it
> >>better be friggin correct and useful, otherwise you will piss a ton of
> >>people off.
> > 
> > 
> > versus the people who are really annoyed that such support hasnt yet been 
> > integrated into portage proper ?
> > 
> > yes, from the portage side of things, it may be a pita to implement 
> > per-package env ... but from the user side of things, it's a huge help
> > -mike
> 
> My e-mail was basically worded as to say "Solar paste your crap to this 
> ML." 

Alright...

tail -n 6 /usr/portage/profiles/uclibc/profile.bashrc

#for conf in ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
#       if [[ -r /etc/portage/env/$CATEGORY/${conf} ]]; then
#               . /etc/portage/env/$CATEGORY/${conf}
#               break
#       fi
#done

>  Is there any reason you need package.env in portage proper as 
> opposed to bashrc?

Nope.. bashrc is the only way to access the variables in a way that 
is the most friendly to the bash side of things.

-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

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

[Alec Warner]

Ned Ludd wrote:
> On Thu, 2006-06-08 at 06:49 -0400, Alec Warner wrote:
> 
>>Mike Frysinger wrote:
>>
>>>On Wednesday 07 June 2006 19:12, Alec Warner wrote:
>>>
>>>
>>>>I would be more concerned with convincing the rest of the developers.
>>>>adding crap in base profile.bashrc will affect 99% of users, so it
>>>>better be friggin correct and useful, otherwise you will piss a ton of
>>>>people off.
>>>
>>>
>>>versus the people who are really annoyed that such support hasnt yet been 
>>>integrated into portage proper ?
>>>
>>>yes, from the portage side of things, it may be a pita to implement 
>>>per-package env ... but from the user side of things, it's a huge help
>>>-mike
>>
>>My e-mail was basically worded as to say "Solar paste your crap to this 
>>ML." 
> 
> 
> Alright...
> 
> tail -n 6 /usr/portage/profiles/uclibc/profile.bashrc
> 
> #for conf in ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
> #       if [[ -r /etc/portage/env/$CATEGORY/${conf} ]]; then
> #               . /etc/portage/env/$CATEGORY/${conf}
> #               break
> #       fi
> #done

Ideas on multipile sources?

Aka, I want all these env things enable for kde-base/* but for 
kde-base/foo I want extra stuff ( or to negate things ), it looks like 
this only sources things once?

Could we define a stacking order here and let them stack?

> 
> 
>> Is there any reason you need package.env in portage proper as 
>>opposed to bashrc?
> 
> 
> Nope.. bashrc is the only way to access the variables in a way that 
> is the most friendly to the bash side of things.
> 

-- 
gentoo-dev@gentoo.org mailing list

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

[Ned Ludd]

On Thu, 2006-06-08 at 09:41 -0400, Alec Warner wrote:
> Ned Ludd wrote:
> > On Thu, 2006-06-08 at 06:49 -0400, Alec Warner wrote:
> > 
> >>Mike Frysinger wrote:
> >>
> >>>On Wednesday 07 June 2006 19:12, Alec Warner wrote:
> >>>
> >>>
> >>>>I would be more concerned with convincing the rest of the developers.
> >>>>adding crap in base profile.bashrc will affect 99% of users, so it
> >>>>better be friggin correct and useful, otherwise you will piss a ton of
> >>>>people off.
> >>>
> >>>
> >>>versus the people who are really annoyed that such support hasnt yet been 
> >>>integrated into portage proper ?
> >>>
> >>>yes, from the portage side of things, it may be a pita to implement 
> >>>per-package env ... but from the user side of things, it's a huge help
> >>>-mike
> >>
> >>My e-mail was basically worded as to say "Solar paste your crap to this 
> >>ML." 
> > 
> > 
> > Alright...
> > 
> > tail -n 6 /usr/portage/profiles/uclibc/profile.bashrc
> > 
> #for conf in ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
> > #       if [[ -r /etc/portage/env/$CATEGORY/${conf} ]]; then
> > #               . /etc/portage/env/$CATEGORY/${conf}
> > #               break
> > #       fi
> > #done
> 
> Ideas on multipile sources?
> 
> Aka, I want all these env things enable for kde-base/* but for 
> kde-base/foo

-for conf in ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
+for conf in default ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do

Call it 'default' ?


>  I want extra stuff ( or to negate things ), it looks like 
> this only sources things once?

yep.

> Could we define a stacking order here and let them stack?

Could remove the break;

 
> >> Is there any reason you need package.env in portage proper as 
> >>opposed to bashrc?
> > 
> > 
> > Nope.. bashrc is the only way to access the variables in a way that 
> > is the most friendly to the bash side of things.
> > 
> 
-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

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

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 342 bytes --]

Ned Ludd wrote:
> -for conf in ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
> +for conf in default ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
> 
> Call it 'default' ?

Switch the order around so it's 'default PN PN-PV PN-PV-PR' -- that way
you can have a package-specific setting, and override it for specific
versions.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Ned Ludd]

On Thu, 2006-06-08 at 07:49 -0700, Donnie Berkholz wrote:
> Ned Ludd wrote:
> > -for conf in ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
> > +for conf in default ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
> > 
> > Call it 'default' ?
> 
> Switch the order around so it's 'default PN PN-PV PN-PV-PR' -- that way
> you can have a package-specific setting, and override it for specific
> versions.

You mean this if only the 'break' is in not in there right?


> 
> Thanks,
> Donnie
> 
-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

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

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 624 bytes --]

Ned Ludd wrote:
> On Thu, 2006-06-08 at 07:49 -0700, Donnie Berkholz wrote:
>> Ned Ludd wrote:
>>> -for conf in ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
>>> +for conf in default ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
>>>
>>> Call it 'default' ?
>> Switch the order around so it's 'default PN PN-PV PN-PV-PR' -- that way
>> you can have a package-specific setting, and override it for specific
>> versions.
> 
> You mean this if only the 'break' is in not in there right?

Didn't catch that on the quick glance -- Actually I'd like if you
removed the break so you can do what I suggested.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Ned Ludd]

On Thu, 2006-06-08 at 09:54 -0700, Donnie Berkholz wrote:
> Ned Ludd wrote:
> > On Thu, 2006-06-08 at 07:49 -0700, Donnie Berkholz wrote:
> >> Ned Ludd wrote:
> >>> -for conf in ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
> >>> +for conf in default ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
> >>>
> >>> Call it 'default' ?
> >> Switch the order around so it's 'default PN PN-PV PN-PV-PR' -- that way
> >> you can have a package-specific setting, and override it for specific
> >> versions.
> > 
> > You mean this if only the 'break' is in not in there right?
> 
> Didn't catch that on the quick glance -- Actually I'd like if you
> removed the break so you can do what I suggested.

This is in the tree now with all suggestions made by everybody and 
works with the new PORTAGE_CONFIGROOT variable also.


-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list