Re: [gentoo-portage-dev] backend support for FEATURES=debug-build (again)

2006-05-16 Thread Mike Frysinger
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 i guess no one has any problems with the current proposed patch ?
-mike


pgpopIuQ2Jfof.pgp
Description: PGP signature


Re: [gentoo-portage-dev] backend support for FEATURES=debug-build (again)

2006-05-13 Thread Mike Frysinger
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-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] backend support for FEATURES=debug-build (again)

2006-05-11 Thread Donnie Berkholz
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



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] backend support for FEATURES=debug-build (again)

2006-05-11 Thread Donnie Berkholz
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



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] backend support for FEATURES=debug-build (again)

2006-05-10 Thread Zac Medico
-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+G41GYA0M5XNG1HEkvbmfwCeIAwB
gXd5JjURKQYAJPKYBUYkrr8=
=zSZM
-END PGP SIGNATURE-
-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] backend support for FEATURES=debug-build (again)

2006-05-10 Thread Mike Frysinger
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-dev@gentoo.org mailing list



[gentoo-portage-dev] backend support for FEATURES=debug-build (again)

2006-05-09 Thread Mike Frysinger
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
Index: pym/portage.py
===
--- pym/portage.py	(revision 3337)
+++ pym/portage.py	(working copy)
@@ -1310,6 +1310,23 @@ class config:
 			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)