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
> >>>
> >>> Ca
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 P
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
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 specif
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
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
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 f
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
> >>use
-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
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.
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 maintai
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
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
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 c
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
-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 perspecti
-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
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'
Somet
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 tak
-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 thr
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
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 th
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 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 Tuesday 24 January 2006 17:56, Donnie Berkholz wrote:
> Mike Frysinger wrote:
> > - we add an emerge flag (say '--debug-build') which adds "nostrip" to
> > FEATURES and auto sets CFLAGS to DEBUG_CFLAGS and LDFLAGS to
> > DEBUG_LDFLAGS - portage will add sane debug defaults to make.globals
> > (D
Mike Frysinger wrote:
> - we add an emerge flag (say '--debug-build') which adds "nostrip" to
> FEATURES
> and auto sets CFLAGS to DEBUG_CFLAGS and LDFLAGS to DEBUG_LDFLAGS
> - portage will add sane debug defaults to make.globals (DEBUG_CFLAGS="-O -g"
> and DEBUG_LDFLAGS="")
I'm having a tough
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
>
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
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
-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 `FEA
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-bui
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
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
> > > "d
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
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 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
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 runti
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 lik
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
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 ge
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"
expli
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 ge
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 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,
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 tw
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 i
-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 x8
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
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 harde
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 PRO
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, 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 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 LDFL
On Tue, 2006-17-01 at 18:03 +0100, Diego 'Flameeyes' Pettenò wrote:
> On Tuesday 17 January 2006 17:51, Olivier Crete wrote:
> > The argument in favor of splitdebug is that it allows users to give
> > useful bugreports when using tools such as gnome's bug-buddy.
> Erm actually it does not. Unless g
On Tuesday 17 January 2006 17:51, Olivier Crete wrote:
> The argument in favor of splitdebug is that it allows users to give
> useful bugreports when using tools such as gnome's bug-buddy.
Erm actually it does not. Unless gnome herd fixed it recently.
The same goes for KCrashHandler/Dr Konqui.
--
On Tue, 2006-17-01 at 08:11 -0700, Richard Fish wrote:
> On 1/15/06, Olivier Crête <[EMAIL PROTECTED]> wrote:
> > Why not use the splitdebug instead of nostrip? And make building with -g
> > the default, then tell small HD users how to disable it in the docs. And
> > it needs to disable -fomit-fram
On Tuesday 17 January 2006 10:11, Richard Fish wrote:
> On 1/15/06, Olivier Crête <[EMAIL PROTECTED]> wrote:
> > Why not use the splitdebug instead of nostrip? And make building with -g
> > the default, then tell small HD users how to disable it in the docs. And
> > it needs to disable -fomit-frame
On 1/15/06, Olivier Crête <[EMAIL PROTECTED]> wrote:
> Why not use the splitdebug instead of nostrip? And make building with -g
> the default, then tell small HD users how to disable it in the docs. And
> it needs to disable -fomit-frame-pointer at least on x86. I've been
> building my whole system
On Sunday 15 January 2006 13:25, Dan Meltzer wrote:
> What would happen on subsequent merges or upgrades if --debug-build
> was omitted? Would there be a way (/etc/portage file perhaps?) to
> enable debug builds on a permanent basis?
i didnt think anyone would want this but it'd be trivial to add
On 1/15/06, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> this topic has come up before too many times and has yet to be solved, and we
> have too many hacks in place
>
> the issues:
> - USE=debug is way too vague; sometimes it builds different code (i.e.
> additional runtime checks, debugging output
On Sun, 2006-15-01 at 01:11 -0500, Mike Frysinger wrote:
> the one true solution:
> - we add an emerge flag (say '--debug-build') which adds "nostrip" to
> FEATURES
> and auto sets CFLAGS to DEBUG_CFLAGS and LDFLAGS to DEBUG_LDFLAGS
Why not use the splitdebug instead of nostrip? And make buildin
On Sunday 15 January 2006 06:52, Henrik Brix Andersen wrote:
> On Sun, Jan 15, 2006 at 01:11:54AM -0500, Mike Frysinger wrote:
> > the one true solution:
> > - USE=debug *never* changes CFLAGS or LDFLAGS or what have you, it *only*
> > enables additional runtime code (such as assert()'s or helpful
On Sun, Jan 15, 2006 at 01:11:54AM -0500, Mike Frysinger wrote:
> the one true solution:
> - 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)
Some packages automatically appends stuff to CFLAG
On Sunday 15 January 2006 01:19, Joshua Baergen wrote:
> Mike Frysinger wrote:
> > - portage will add sane debug defaults to make.globals (DEBUG_CFLAGS="-O
> > -g" and DEBUG_LDFLAGS="")
>
> Nothing huge, but won't this fry certain systems (SPARC iirc, among
> others) that need the -march informatio
Mike Frysinger wrote:
- portage will add sane debug defaults to make.globals (DEBUG_CFLAGS="-O -g"
and DEBUG_LDFLAGS="")
Nothing huge, but won't this fry certain systems (SPARC iirc, among
others) that need the -march information for the code to even run? If
so, the solution would have to g
65 matches
Mail list logo
