backend support for FEATURES=debug-build (again)

no one responded last time about this patch so lets try one
more time :P

backend support for FEATURES=debug-build ... no
hooks/hacks/etc... included 
here to handle a user interface `emerge --debug-build`
-mike

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

Mike Frysinger wrote:
> no one responded last time about this patch so lets try
one more time :P
> 
> backend support for FEATURES=debug-build ... no
hooks/hacks/etc... included 
> here to handle a user interface `emerge --debug-build`
> -mike

This type of thing can already be done quite easily via
/etc/portage/bashrc.  Is it really necessary to add support
for small environment tweaks like this on the python side?

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

iD8DBQFEYhMC/ejvha5XGaMRAu8pAJ0S4sAf+G41GYA0M5XNG1HEkvbmfwCe
IAwB
gXd5JjURKQYAJPKYBUYkrr8=
=zSZM
-----END PGP SIGNATURE-----
-- 
gentoo-portage-devgentoo.org mailing list

On Wednesday 10 May 2006 12:21, Zac Medico wrote:
> Mike Frysinger wrote:
> > no one responded last time about this patch so
lets try one more time :P
> >
> > backend support for FEATURES=debug-build ... no
hooks/hacks/etc...
> > included here to handle a user interface `emerge
--debug-build`
>
> This type of thing can already be done quite easily via
> /etc/portage/bashrc.

so ?  you cant expect every user who wants to do debug
building to add hacks 
to their own bashrc

> Is it really necessary to add support for small 
> environment tweaks like this on the python side?

yes, it's a user-friendly interface issue:
we have *no* *sane* way of doing a debug emerge
-mike
-- 
gentoo-portage-devgentoo.org mailing list

Mike Frysinger wrote:
> yes, it's a user-friendly interface issue:
> we have *no* *sane* way of doing a debug emerge

I don't find this particular implementation very
user-friendly either,
since AFAIK the FEATURES settings still aren't remembered
or settable on
a per-package level.

That's why x-modular.eclass has USE=debug to accomplish the
same thing.

Thanks,
Donnie

On Thursday 11 May 2006 02:41, Donnie Berkholz wrote:
> Mike Frysinger wrote:
> > yes, it's a user-friendly interface issue:
> > we have *no* *sane* way of doing a debug emerge
>
> I don't find this particular implementation very
user-friendly either,

if you read my original e-mail in this thread (or even the
subject), i said 
this is the back-end changes *only*

the next step is to add `emerge --debug-build foo`

> since AFAIK the FEATURES settings still aren't
remembered

nor should they

> or settable on a per-package level.

unrelated topic, see per-package.env bug

> That's why x-modular.eclass has USE=debug to
accomplish the same thing.

which is totally wrong

read the thread i started on gentoo-dev where i went over
how USE=debug in the 
portage tree is complete trash atm
-mike
-- 
gentoo-portage-devgentoo.org mailing list

On Tue, 2006-05-09 at 22:43 -0400, Mike Frysinger wrote:
> no one responded last time about this patch so lets try
one more time :P
> 
> backend support for FEATURES=debug-build ... no
hooks/hacks/etc... included 
> here to handle a user interface `emerge --debug-build`
> -mike

I like the basic idea exactly how you have it implemented.

-- 
Ned Ludd <solargentoo.org>
Gentoo Linux

-- 
gentoo-portage-devgentoo.org mailing list

Mike Frysinger wrote:
> On Thursday 11 May 2006 02:41, Donnie Berkholz wrote:
>> Mike Frysinger wrote:
>>> yes, it's a user-friendly interface issue:
>>> we have *no* *sane* way of doing a debug emerge
>> I don't find this particular implementation very
user-friendly either,
> 
> if you read my original e-mail in this thread (or even
the subject), i said 
> this is the back-end changes *only*
> 
> the next step is to add `emerge --debug-build foo`
> 
>> since AFAIK the FEATURES settings still aren't
remembered
> 
> nor should they
> 
>> or settable on a per-package level.
> 
> unrelated topic, see per-package.env bug
> 
>> That's why x-modular.eclass has USE=debug to
accomplish the same thing.
> 
> which is totally wrong
> 
> read the thread i started on gentoo-dev where i went
over how USE=debug in the 
> portage tree is complete trash atm

It may be wrong, but it's the only way that works usefully.
This is
totally useless IMHO until you can set it on a per-package
level, so
they are related.

Thanks,
Donnie

On Thursday 11 May 2006 14:23, Donnie Berkholz wrote:
> Mike Frysinger wrote:
> > On Thursday 11 May 2006 02:41, Donnie Berkholz
wrote:
> >> That's why x-modular.eclass has USE=debug to
accomplish the same thing.
> >
> > which is totally wrong
> >
> > read the thread i started on gentoo-dev where i
went over how USE=debug
> > in the portage tree is complete trash atm
>
> It may be wrong, but it's the only way that works
usefully.

so you'd rather stick with a known crappy/inconsistent
methodology then move 
in the proper direction ?

this debug-build FEATURES is the proper direction

> This is totally useless IMHO until you can set it on a
per-package level,

bashrc hacks can add insert FEATURES on a per package basis
until proper 
portage support is in place, but unlike the previous bashrc
suggestion, this 
is a stop gap, not the correct, solution

i'm willing to forgo this (imo) minor aspect in favor of
cutting the 
unreliable USE=debug from the tree
-mike
-- 
gentoo-portage-devgentoo.org mailing list

Mike Frysinger wrote:
> On Thursday 11 May 2006 14:23, Donnie Berkholz wrote:
>> Mike Frysinger wrote:
>>> On Thursday 11 May 2006 02:41, Donnie Berkholz
wrote:
>>>> That's why x-modular.eclass has USE=debug
to accomplish the same thing.
>>> which is totally wrong
>>>
>>> read the thread i started on gentoo-dev where i
went over how USE=debug
>>> in the portage tree is complete trash atm
>> It may be wrong, but it's the only way that works
usefully.
> 
> so you'd rather stick with a known crappy/inconsistent
methodology then move 
> in the proper direction ?
> 
> this debug-build FEATURES is the proper direction

I agree with the direction, when one includes the
per-package env bit.

>> This is totally useless IMHO until you can set it
on a per-package level,
> 
> bashrc hacks can add insert FEATURES on a per package
basis until proper 
> portage support is in place, but unlike the previous
bashrc suggestion, this 
> is a stop gap, not the correct, solution
> 
> i'm willing to forgo this (imo) minor aspect in favor
of cutting the 
> unreliable USE=debug from the tree

I'm not. But I will agree that this is the correct
direction. Once both
parts of the puzzle are in place, then I will support
cutting USE=debug
-- but not until one can reproduce its functionality sans
hacks. No
point in replacing one hack with another.

Thanks,
Donnie

On Tuesday 09 May 2006 22:43, Mike Frysinger wrote:
> no one responded last time about this patch so lets try
one more time :P
>
> backend support for FEATURES=debug-build ... no
hooks/hacks/etc... included
> here to handle a user interface `emerge --debug-build`

so do we have anyone against this ?  if not i'll merge it
later this weekend
-mike
-- 
gentoo-portage-devgentoo.org mailing list