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' ?
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
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
-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
On Thu, 08 Jun 2006 06:49:39 -0400
Alec Warner [EMAIL PROTECTED] 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
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
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
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
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
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
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
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'
-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
Alec Warner [EMAIL PROTECTED] 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
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
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
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
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
debug stuff
#endif
And likewise your code should NOT have some logic like the following in
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.
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,
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
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
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
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
On Fri, Jan 20, 2006 at 07:10:02AM -0500, Mike Frysinger wrote:
that depends, does your code actually have things like
#ifdef DEBUG
debug stuff
#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
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
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
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
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
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
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
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
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
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
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
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
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
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
38 matches
Mail list logo
