Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Sunday 15 January 2006 01:11, Mike Frysinger wrote: > this topic has come up before too many times and has yet to be solved, and > we have too many hacks in place ok, so after sitting on the list for a while and accumulating feedback, how about this: - USE=debug *never* changes CFLAGS or LDFLAGS or what have you, it *only* enables additional runtime code (such as assert()'s or helpful debug output) ... if you're confused by what i mean, run `USE=debug emerge nano` and then run `nano` - we add an emerge flag (say '--debug-build') which adds "debug-build" to FEATURES - if "debug-build" is in FEATURES, then the following happens: * auto sets CFLAGS to DEBUG_CFLAGS, LDFLAGS to DEBUG_LDFLAGS, CXXFLAGS to DEBUG_CXXFLAGS (and in the future, we can add more variables as the need comes up) * if user already has FEATURES=splitdebug, then do not add "nostrip" * if user does not have FEATURES=splitdebug, then add "nostrip" to FEATURES - we will set sane debug defaults in the base profile: * DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g" * DEBUG_LDFLAGS="" - subprofiles can tweak these values as they see fit (or as required) i'll go ahead and start implementing framework for this in the meantime -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Thu, 2006-19-01 at 17:56 -0500, Mike Frysinger wrote:
> - USE=debug *never* changes CFLAGS or LDFLAGS or what have you, it *only*
> enables additional runtime code (such as assert()'s or helpful debug
> output) ... if you're confused by what i mean, run `USE=debug emerge nano`
> and then run `nano`
This is so overdue..
+1
> - if "debug-build" is in FEATURES, then the following happens:
> * auto sets CFLAGS to DEBUG_CFLAGS, LDFLAGS to DEBUG_LDFLAGS, CXXFLAGS to
> DEBUG_CXXFLAGS (and in the future, we can add more variables as the need
> comes up)
What about: CFLAGS="${CFLAGS} ${DEBUG_CFLAGS}" .. otherwise bugs that
only appear after certain GCC optmisations may go away...
> - we will set sane debug defaults in the base profile:
> * DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g"
I'd propose "-fno-omit-frame-pointer -ggdb" for x86/amd64 and "-g" for
default...
--
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Thu, Jan 19, 2006 at 05:56:47PM -0500, Mike Frysinger wrote: > ok, so after sitting on the list for a while and accumulating feedback, how > about this: [snip] > i'll go ahead and start implementing framework for this in the meantime Sounds like a sane approach to me - thank you for putting in the work for getting this implemented. Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgpHLLSclxutz.pgp Description: PGP signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Thu, Jan 19, 2006 at 06:17:11PM -0500, Olivier Crete wrote:
> What about: CFLAGS="${CFLAGS} ${DEBUG_CFLAGS}" .. otherwise bugs that
> only appear after certain GCC optmisations may go away...
The user can set any DEBUG_CFLAGS she likes in make.conf.
./Brix
--
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd
pgpup55o2U6Db.pgp
Description: PGP signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Thu, 2006-01-19 at 17:56 -0500, Mike Frysinger wrote: DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g" Mike, how about DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g -fno-stack-protector -fno-pie" All Gentoo properly supported toolchains support the last two flags and it ensures that debugging almost works for hardened users too. I'd say I could just run with the extra flags in the hardened/* profiles but it seems a good portion of the users these days seem to be vanilla users using 'gcc-config > 1' -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
solar <[EMAIL PROTECTED]> said: > On Thu, 2006-01-19 at 17:56 -0500, Mike Frysinger wrote: > DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g" > > Mike, > how about > DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g -fno-stack-protector -fno-pie" > > All Gentoo properly supported toolchains support the last two flags and > it ensures that debugging almost works for hardened users too. Please lets avoid this assumption. I'd love to make it so we never make this assumption anywhere in the tree so that we could actually build GCC without pie or ssp, instead of generating all of the GCC profiles for every user. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgp0U9HtGxgjW.pgp Description: PGP signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Olivier Crete schrieb: |>- we will set sane debug defaults in the base profile: |> * DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g" | | | I'd propose "-fno-omit-frame-pointer -ggdb" for x86/amd64 and "-g" for | default... Make that -fno-omit-frame-pointer for x86 only. amd64 has no problems wrt to debuging frame-pointer-less executables. Danny - -- Danny van Dyk <[EMAIL PROTECTED]> Gentoo/AMD64 Project, Gentoo Scientific Project -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD0CumaVNL8NrtU6IRApKQAKCF4ZWSpU26lMEA8NRa8xFpWDEgWACePs4s c4ReLSGnAciwDVgQdvHSvrw= =BTJz -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Thursday 19 January 2006 18:52, Mark Loeser wrote: > Please lets avoid this assumption. I'd love to make it so we never make > this assumption anywhere in the tree so that we could actually build GCC > without pie or ssp, instead of generating all of the GCC profiles for every > user. pie is in upstream gcc so your argument here is INVALID please move along, kthx -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Thursday 19 January 2006 18:33, solar wrote: > On Thu, 2006-01-19 at 17:56 -0500, Mike Frysinger wrote: > DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g" > > Mike, > how about > DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g -fno-stack-protector -fno-pie" > > All Gentoo properly supported toolchains support the last two flags and > it ensures that debugging almost works for hardened users too. > I'd say I could just run with the extra > flags in the hardened/* profiles but it seems a good portion of the > users these days seem to be vanilla users using 'gcc-config > 1' to please the whiners, we can use: -O -g -fno-pie and keep the -fno-ssp in hardened profiles -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Thursday 19 January 2006 18:17, Olivier Crete wrote:
> On Thu, 2006-19-01 at 17:56 -0500, Mike Frysinger wrote:
> > - if "debug-build" is in FEATURES, then the following happens:
> > * auto sets CFLAGS to DEBUG_CFLAGS, LDFLAGS to DEBUG_LDFLAGS, CXXFLAGS
> > to DEBUG_CXXFLAGS (and in the future, we can add more variables as the
> > need comes up)
>
> What about: CFLAGS="${CFLAGS} ${DEBUG_CFLAGS}" .. otherwise bugs that
> only appear after certain GCC optmisations may go away...
then we'll deal with that ... we're trying to debug bad code, not bad code
generation
> > - we will set sane debug defaults in the base profile:
> > * DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g"
>
> I'd propose "-fno-omit-frame-pointer -ggdb" for x86/amd64 and "-g" for
> default...
why ? -fomit-frame-pointer is only used with -O whenever it doesnt interfere
with debugging ... in other words, -O on x86 will not imply
-fomit-framer-pointer
and as noted, x86_64 doesnt suck like x86, so this isnt an issue for amd64 :)
-mike
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
Mike Frysinger wrote: - we will set sane debug defaults in the base profile: * DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g" On gcc-4, even -O can make it really hard to track stuff. Might want -O0 instead. 4.1 gets even crazier. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Thu, 19 Jan 2006 19:24:18 -0800 Donnie Berkholz <[EMAIL PROTECTED]> wrote: | Mike Frysinger wrote: | > - we will set sane debug defaults in the base profile: | > * DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g" | | On gcc-4, even -O can make it really hard to track stuff. Might want | -O0 instead. 4.1 gets even crazier. -O1 -fno-inline-functions will give you better results with C++ code. Without -O1, g++ will skip some really basic optimisations that makes it even harder than usual to figure out what STL code is doing... -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Thu, Jan 19, 2006 at 05:56:47PM -0500, Mike Frysinger wrote: > - USE=debug *never* changes CFLAGS or LDFLAGS or what have you, it *only* > enables additional runtime code (such as assert()'s or helpful debug > output) ... I'd like to see cases such as "use debug && append-flags -DDEBUG" explicitly mentioned, please. I'm sure you meant that this is okay, but to avoid confusion, could you actually say so? (Or, if I'm completely misunderstanding, tell me it's not okay. :) pgpl3dqm0NRzA.pgp Description: PGP signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Thu, 19 Jan 2006 18:33:02 -0500 solar <[EMAIL PROTECTED]> wrote: > On Thu, 2006-01-19 at 17:56 -0500, Mike Frysinger wrote: > DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g" > > Mike, > how about > DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g -fno-stack-protector -fno-pie" It's enough to do LDFLAGS="-nopie" to get debuggable executables, which might be better as it'd keep code closer to the non-debug code. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Thu, 19 Jan 2006 19:28:53 -0500 Mike Frysinger <[EMAIL PROTECTED]> wrote: > On Thursday 19 January 2006 18:52, Mark Loeser wrote: > > Please lets avoid this assumption. I'd love to make it so we never > > make this assumption anywhere in the tree so that we could actually > > build GCC without pie or ssp, instead of generating all of the GCC > > profiles for every user. SPLIT_SPECS="no" in make.conf causes just the profile default to be built - is that good enough? > pie is in upstream gcc so your argument here is INVALID and -fno-stack-protector is only a problem if gcc-4.0 is built without the ssp-stubs - from 4.1 onwards that'll be upstream as well. Having said that, I don't think we need -fno-stack-protector in default DEBUG_FLAGS anyway, as it doesn't inhibit debug (unlike -Wl,pie). -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Friday 20 January 2006 01:25, Harald van Dijk wrote: > On Thu, Jan 19, 2006 at 05:56:47PM -0500, Mike Frysinger wrote: > > - USE=debug *never* changes CFLAGS or LDFLAGS or what have you, it *only* > > enables additional runtime code (such as assert()'s or helpful debug > > output) ... > > I'd like to see cases such as "use debug && append-flags -DDEBUG" > explicitly mentioned, please. I'm sure you meant that this is okay, but > to avoid confusion, could you actually say so? (Or, if I'm completely > misunderstanding, tell me it's not okay. :) that depends, does your code actually have things like #ifdef DEBUG #endif -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Fri, Jan 20, 2006 at 07:10:02AM -0500, Mike Frysinger wrote: > On Friday 20 January 2006 01:25, Harald van Dijk wrote: > > On Thu, Jan 19, 2006 at 05:56:47PM -0500, Mike Frysinger wrote: > > > - USE=debug *never* changes CFLAGS or LDFLAGS or what have you, it *only* > > > enables additional runtime code (such as assert()'s or helpful debug > > > output) ... > > > > I'd like to see cases such as "use debug && append-flags -DDEBUG" > > explicitly mentioned, please. I'm sure you meant that this is okay, but > > to avoid confusion, could you actually say so? (Or, if I'm completely > > misunderstanding, tell me it's not okay. :) > > that depends, does your code actually have things like > #ifdef DEBUG > > #endif screen (which is what I got it from) does. pgpuJ8T5Qw71t.pgp Description: PGP signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Fri, Jan 20, 2006 at 07:10:02AM -0500, Mike Frysinger wrote: > that depends, does your code actually have things like > #ifdef DEBUG > > #endif And likewise your code should NOT have some logic like the following in it's build system. if(debug mode) ignore user cflags and use our own cracked out cflags I've seen an upstream configure script where if you tell it you want debug mode, the only thing it does is force CFLAGS to '-O -march=i386' and not strip the binaries itself - this of course failed dismally when you tried to enable debugging on non-x86 platforms. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpMDVGXmRWcR.pgp Description: PGP signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
Mike Frysinger wrote: On Sunday 15 January 2006 01:11, Mike Frysinger wrote: - we add an emerge flag (say '--debug-build') which adds "debug-build" to FEATURES IMO this is pointless and redundant. But otherwise the proposal looks good. Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Saturday 21 January 2006 23:12, Marius Mauch wrote: > Mike Frysinger wrote: > > On Sunday 15 January 2006 01:11, Mike Frysinger wrote: > > > > - we add an emerge flag (say '--debug-build') which adds "debug-build" to > > FEATURES > > IMO this is pointless and redundant. its purpose is to handle cases where user wants to always have a package built in this manner (ferringb mentioned it as a possibility and someone else mentioned they would like it) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Sun, 22 Jan 2006 14:45:34 -0500 Mike Frysinger <[EMAIL PROTECTED]> wrote: > On Saturday 21 January 2006 23:12, Marius Mauch wrote: > > Mike Frysinger wrote: > > > On Sunday 15 January 2006 01:11, Mike Frysinger wrote: > > > > > > - we add an emerge flag (say '--debug-build') which adds > > > "debug-build" to FEATURES > > > > IMO this is pointless and redundant. > > its purpose is to handle cases where user wants to always have a > package built in this manner (ferringb mentioned it as a possibility > and someone else mentioned they would like it) I meant the option is redundant if it just triggers a feature setting, as it's the same as `FEATURES=debug-build emerge foo` -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Sunday 22 January 2006 16:30, Marius Mauch wrote: > I meant the option is redundant if it just triggers a feature setting, > as it's the same as `FEATURES=debug-build emerge foo` as noted in earlier proposal: > - no easy way for users/developers to quickly emerge a package and have it > contain useful debugging information, running `FEATURES=nostrip CFLAGS="-g > -O" emerge booga` is petarded -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
Marius Mauch wrote: > On Sun, 22 Jan 2006 14:45:34 -0500 > Mike Frysinger <[EMAIL PROTECTED]> wrote: > >> On Saturday 21 January 2006 23:12, Marius Mauch wrote: >>> Mike Frysinger wrote: On Sunday 15 January 2006 01:11, Mike Frysinger wrote: - we add an emerge flag (say '--debug-build') which adds "debug-build" to FEATURES >>> IMO this is pointless and redundant. >> its purpose is to handle cases where user wants to always have a >> package built in this manner (ferringb mentioned it as a possibility >> and someone else mentioned they would like it) > > I meant the option is redundant if it just triggers a feature setting, > as it's the same as `FEATURES=debug-build emerge foo` OK, where's my package.features and packages.cflags files then? I can do what I want through Mike's proposal, which is to build a specific collection of packages with debugging. I also don't need to duplicate the same list of packages in one file with FEATURES=nostrip and in another with debugging CFLAGS. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Saturday 21 January 2006 00:25, Robin H. Johnson wrote: > On Fri, Jan 20, 2006 at 07:10:02AM -0500, Mike Frysinger wrote: > > that depends, does your code actually have things like > > #ifdef DEBUG > > > > #endif > > And likewise your code should NOT have some logic like the following in > it's build system. > if(debug mode) >ignore user cflags and use our own cracked out cflags > > I've seen an upstream configure script where if you tell it you want > debug mode, the only thing it does is force CFLAGS to '-O -march=i386' > and not strip the binaries itself - this of course failed dismally when > you tried to enable debugging on non-x86 platforms. Actually kde (and as such most kde apps) does all kinds of awkward stuff in it's configure script too with respect to adding the "--enable-debug" flag. Although it mostly involves making the compiler extremely noisy, and forcing in "-g" flags. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpSbjr63bzpH.pgp Description: PGP signature
"Environement categories" (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
[Please excuse the improper naming for this subject. I'll take any
suggestions to improve it :-) ]
Donnie Berkholz schrieb:
| Marius Mauch wrote:
|>I meant the option is redundant if it just triggers a feature setting,
|>as it's the same as `FEATURES=debug-build emerge foo`
|
| OK, where's my package.features and packages.cflags files then? I can do
| what I want through Mike's proposal, which is to build a specific
| collection of packages with debugging. I also don't need to duplicate
| the same list of packages in one file with FEATURES=nostrip and in
| another with debugging CFLAGS.
I'd love to have one package.env (or similarly named) file that can set
environmental options on a per-package-base. This is just a proposal,
but i personally would like it this way:
# First define a category of environmental options:
stable=( \
"ACCEPT_KEYWORDS=\"arch\"" \
"CFLAGS=\"-pipe -O -march=foo\"" \
)
debug=( \
"FEATURES=\"debug-build keepwork\"" \
"CFLAGS=\"-pipe -O0 -ggdb\"" \
)
# then tell portage to use a env-category for certain packages:
app-foo/totallybroken debug
=app-bar/anotherbrokenpkg debug
# Also, system packages should get their own category that would
# be used by default on them.
system=( \
"ACCEPT_KEYWORDS=\"arch\"" \
"FEATURES=\"buildpkg\"" \
)
This proposed format could even be more easily parsed when split into to
files. One file to define the categories and one to define the
package-to-category bindings. The first file would be pure bash and
could be loaded like this:
mycat=$(
. ${CATEGORY_FILE}
cat=${!cat}
for i in $(seq 0 $(( [EMAIL PROTECTED] - 1)) ) ; do
echo -e "${cat[${i}]}"
done
)
Comments? Please keep in mind that the code snippets here are just
proof-of-concept code and not meant literally!
Danny
- --
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD1SA1aVNL8NrtU6IRAn/eAKCl2VcCAayy6TgsU3voRZvd+JQtOgCgpXNX
+9G+//2+O/DxhcSXXyMjE6w=
=LtXA
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
Re: "Environement categories" (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)
On Monday 23 January 2006 13:28, Danny van Dyk wrote: > I'd love to have one package.env (or similarly named) file that can set > environmental options on a per-package-base. i thought this was already implemented -mike -- gentoo-dev@gentoo.org mailing list
Re: "Environement categories" (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)
On Mon, Jan 23, 2006 at 07:28:05PM +0100, Danny van Dyk wrote:
> Donnie Berkholz schrieb:
> | Marius Mauch wrote:
> |>I meant the option is redundant if it just triggers a feature setting,
> |>as it's the same as `FEATURES=debug-build emerge foo`
> |
> | OK, where's my package.features and packages.cflags files then? I can do
> | what I want through Mike's proposal, which is to build a specific
> | collection of packages with debugging. I also don't need to duplicate
> | the same list of packages in one file with FEATURES=nostrip and in
> | another with debugging CFLAGS.
>
> I'd love to have one package.env (or similarly named) file that can set
> environmental options on a per-package-base. This is just a proposal,
> but i personally would like it this way:
>
> # First define a category of environmental options:
> stable=( \
> "ACCEPT_KEYWORDS=\"arch\"" \
> "CFLAGS=\"-pipe -O -march=foo\"" \
> )
We've already got package.keywords...
Not saying it's the best, but muddying up the existing configuration
with N ways of saying the same thing imo isn't the sanest.
> debug=( \
> "FEATURES=\"debug-build keepwork\"" \
And there is the kicker. Portage has globals, which are in various
states of use- most of the features you're looking to tweak *are*
effectively globals already.
So... you need seperate configuration instances. This gets ugly since
not all code uses a passed in config instance, some falls back to
global access (just the same as not all code uses passed in dbapi's,
they use the global portage.db).
The config representation does a nasty little dance where it pushes
changes on, then pops them (moreso it just flat out regenerates the
settings)- extending usage of that really isn't a good thing imo,
since it's fundamentally the wrong design. Hell, such an approach
won't fly anyways for any real possibility of threaded execution
(parallel-fetch doesn't count, it's a fork for exactly this reason).
See where I'm going with this, and why the portage crew occasionally
make reference to design flaws? :)
Might I suggest this one just get shelved for a while? I'm not much
for spanky's proposal from an implementation side of things, but it
skirts the areas I'm concerned about (thus I'm mostly neutral on it),
but varying all configuration data per node is a whole different beast
from spanky's proposal- it's not skirting the areas that are icky.
Realistically, need to design the bugger so configuration data is
pushed down to each level/abstraction rather then a global obj; do
that, and it's easy to vary settings per node; rewrite is designed
this way, just not finished.
Personally, I'd rather revisit this a few months down the line- right
now it's too nasty of a hack to even consider it in stable.
> This proposed format could even be more easily parsed when split into to
> files. One file to define the categories and one to define the
> package-to-category bindings. The first file would be pure bash and
> could be loaded like this:
>
> mycat=$(
> . ${CATEGORY_FILE}
> cat=${!cat}
> for i in $(seq 0 $(( [EMAIL PROTECTED] - 1)) ) ; do
> echo -e "${cat[${i}]}"
> done
> )
Bash side overrides are a no go; either the resolver would have to
spawn a shell instance for processing each node, or portage would have
to know how to parse and execute shell (hard... very hard).
So... at least the bash side of it, not really doable imo. Same
reason you can't use bashrc to affect features (for the most part),
by the time that code is executed it's too late in the game.
~harring
pgpZMabwXoRwB.pgp
Description: PGP signature
Re: "Environement categories" (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)
On Tuesday 24 January 2006 01:44, Brian Harring wrote: > Might I suggest this one just get shelved for a while? everything that gets shelved portage way stays that way for *quite* a while i would be ok with implementing the back end (i.e. FEATURES=debug-build) but putting off the front end (i.e. emerge --debug-build) -mike -- gentoo-dev@gentoo.org mailing list
Re: "Environement categories" (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)
On Tue, Jan 24, 2006 at 08:06:12PM -0500, Mike Frysinger wrote: > On Tuesday 24 January 2006 01:44, Brian Harring wrote: > > Might I suggest this one just get shelved for a while? > > everything that gets shelved portage way stays that way for *quite* a while If people don't give a damn about it, yes, that's true. Not the case here. > i would be ok with implementing the back end (i.e. FEATURES=debug-build) but > putting off the front end (i.e. emerge --debug-build) Front-end doesn't matter, it's the back-end that's the concern. Clean up the backend in stable, and it's fine- hence the "shelve it"; fix the backend instead of tagging it half way in. ~harring pgpnXO9Ud50CA.pgp Description: PGP signature
Re: "Environement categories" (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)
On Wednesday 25 January 2006 02:26, Brian Harring wrote:
> On Tue, Jan 24, 2006 at 08:06:12PM -0500, Mike Frysinger wrote:
> > i would be ok with implementing the back end (i.e. FEATURES=debug-build)
> > but putting off the front end (i.e. emerge --debug-build)
>
> Front-end doesn't matter, it's the back-end that's the concern. Clean
> up the backend in stable, and it's fine- hence the "shelve it"; fix
> the backend instead of tagging it half way in.
what exactly is "half way" about the attached patch ?
-mike
Index: pym/portage.py
===
--- pym/portage.py (revision 2604)
+++ pym/portage.py (working copy)
@@ -1263,6 +1263,23 @@
if "usersandbox" in self.features:
self.features.remove("usersandbox")
+ if "debug-build" in self.features:
+ # the profile should be setting these, but just in case ...
+ if not len(self["DEBUG_CFLAGS"]):
+self["DEBUG_CFLAGS"] = "-g -O"
+self.backup_changes("DEBUG_CFLAGS")
+ if not len(self["DEBUG_CXXFLAGS"]):
+self["DEBUG_CXXFLAGS"] = self["DEBUG_CFLAGS"]
+self.backup_changes("DEBUG_CXXFLAGS")
+ # replace user vars with debug version
+ for var in ["CFLAGS","CXXFLAGS","LDFLAGS"]:
+self[var]=self["DEBUG_"+var]
+self.backup_changes(var)
+ # if user has splitdebug, the debug info will be auto saved for
+ # gdb, otherwise we want to keep the binaries from being stripped
+ if not "splitdebug" in self.features:
+self.features.append("nostrip")
+
self.features.sort()
self["FEATURES"] = " ".join(["-*"]+self.features)
self.backup_changes("FEATURES")
Index: pym/portage_const.py
===
--- pym/portage_const.py (revision 2604)
+++ pym/portage_const.py (working copy)
@@ -40,7 +40,7 @@
CONFIG_MEMORY_FILE = PRIVATE_PATH + "/config"
INCREMENTALS=["USE","USE_EXPAND","USE_EXPAND_HIDDEN","FEATURES","ACCEPT_KEYWORDS","ACCEPT_LICENSE","CONFIG_PROTECT_MASK","CONFIG_PROTECT","PRELINK_PATH","PRELINK_PATH_MASK"]
-STICKIES=["KEYWORDS_ACCEPT","USE","CFLAGS","CXXFLAGS","MAKEOPTS","EXTRA_ECONF","EXTRA_EINSTALL","EXTRA_EMAKE"]
+STICKIES=["KEYWORDS_ACCEPT","USE","CFLAGS","CXXFLAGS","LDFLAGS","DEBUG_CFLAGS","DEBUG_CXXFLAGS","DEBUG_LDFLAGS","MAKEOPTS","EXTRA_ECONF","EXTRA_EINSTALL","EXTRA_EMAKE"]
EBUILD_PHASES = ["setup","unpack","compile","test","install","preinst","postinst","prerm","postrm"]
EAPI = 0
