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 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
51 matches
Mail list logo
