Re: [gentoo-dev] New eclass: scons.eclass

2010-10-07 Thread Donnie Berkholz 
On 20:26 Wed 06 Oct , Michał Górny wrote:
 On Wed, 6 Oct 2010 12:52:33 -0500
 Donnie Berkholz dberkh...@gentoo.org wrote:
 
 local flag=${1}
 local varname=${2:-${flag#!}}
  
  Could you explain how this works to me, please? It seems like you're 
  reversing the logic when people use the !flag syntax.
 
 It's just the variable (macro) name; the 'flag' var passes ! to use.
 This stripping is just intended to avoid outputting things like
 '!ssl=1' by default, and avoid guesses like 'nossl'.

So what happens if I want the !use syntax and say `use_scons !ssl 
nossl`?

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com


pgp42hkC2CYUL.pgp
Description: PGP signature

Re: [gentoo-dev] New eclass: scons.eclass

2010-10-07 Thread Michał Górny 
On Thu, 7 Oct 2010 22:08:30 -0500
Donnie Berkholz dberkh...@gentoo.org wrote:

 So what happens if I want the !use syntax and say `use_scons !ssl 
 nossl`?

${2} is set then, and ${flag#!} isn't even evaluated.

BTW I've changed that already to make $(use_scons !ssl) output nossl.
This should be more logical.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] New eclass: scons.eclass

2010-10-06 Thread Donnie Berkholz 
On 20:57 Tue 05 Oct , Michał Górny wrote:
 # @FUNCTION: use_scons
 # @USAGE: use-flag [var-name] [var-opt-true] [var-opt-false]
 # @DESCRIPTION:
 # Output an SCons parameter with value depending on the USE flag state.
 # If the USE flag is set, output var-name=var-opt-true; otherwise
 # var-name=var-opt-false.
 #
 # If var-name is not set, use-flag will be used instead.
 # If var-opt-true or var-opt-false is unset, USE_SCONS_TRUE
 # or USE_SCONS_FALSE will be used instead.
 use_scons() {
   local flag=${1}
   local varname=${2:-${flag#!}}

Could you explain how this works to me, please? It seems like you're 
reversing the logic when people use the !flag syntax.

   local vartrue=${3:-${USE_SCONS_TRUE}}
   local varfalse=${4:-${USE_SCONS_FALSE}}

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com


pgpmj3AYH1Q1S.pgp
Description: PGP signature

Re: [gentoo-dev] New eclass: scons.eclass

2010-10-06 Thread Michał Górny 
On Wed, 6 Oct 2010 12:52:33 -0500
Donnie Berkholz dberkh...@gentoo.org wrote:

  local flag=${1}
  local varname=${2:-${flag#!}}
 
 Could you explain how this works to me, please? It seems like you're 
 reversing the logic when people use the !flag syntax.

It's just the variable (macro) name; the 'flag' var passes ! to use.
This stripping is just intended to avoid outputting things like
'!ssl=1' by default, and avoid guesses like 'nossl'.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] New eclass: scons.eclass

2010-08-24 Thread Michał Górny 
On Mon, 23 Aug 2010 19:27:22 -0400
Mike Frysinger vap...@gentoo.org wrote:

 then keep it simple and separate:
 escons() {
   debug-print-function ${FUNCNAME} $...@}
 
   set -- scons $(scons_clean_makeopts) ${SCONSOPTS}
 ${EXTRA_ESCONS} $...@} echo $...@} 2
   $...@}
 }
 
 now you dont have to worry about changes between invocations and the
 developer has a clear path -- if they need to force a serial build
 for example, they can either append MAKEOPTS, SCONSOPTS, or pass it
 straight to escons.  no cache confusion or desync between the vars.

Ok, but will use ${SCONSOPTS-$(scons_clean_makeopts)} instead.
The point is that the user can decide to have different SCONSOPTS set
in his/her make.conf, and he/she couldn't magically drop MAKEOPTS for
SCons ebuilds then.

Additionally, I will implement the cache in scons_clean_makeopts().
That should work just fine.

-- 
Best regards,
Michał Górny

http://mgorny.alt.pl
xmpp:mgo...@jabber.ru


signature.asc
Description: PGP signature

Re: [gentoo-dev] New eclass: scons.eclass

2010-08-24 Thread Michał Górny 
On Mon, 23 Aug 2010 19:36:50 +0200
Maciej Mrozowski reave...@gmail.com wrote:

 If SCons is unpredictable, then don't provide *any* phases and only
 functions and rename it to scons-utils to match its purpose.

It is as predictable as the buildsystem meeting the default phase
functions requirements -- we can configure it, compile it but no way of
knowing what should be done in 'install' for sure.

 What I hate is deliberately introduced inconsistency in ebuild API's.

What I hate is replicating bad practices just because someone else did
that before. If I'm wrong, then please point me the relation between
a particular buildsystem and patching.

-- 
Best regards,
Michał Górny

http://mgorny.alt.pl
xmpp:mgo...@jabber.ru


signature.asc
Description: PGP signature

Re: [gentoo-dev] New eclass: scons.eclass

2010-08-24 Thread Maciej Mrozowski 
On Tuesday 24 of August 2010 10:30:12 Michał Górny wrote:
 On Mon, 23 Aug 2010 19:36:50 +0200
 
 Maciej Mrozowski reave...@gmail.com wrote:
  If SCons is unpredictable, then don't provide *any* phases and only
  functions and rename it to scons-utils to match its purpose.
 
 It is as predictable as the buildsystem meeting the default phase
 functions requirements -- we can configure it, compile it but no way of
 knowing what should be done in 'install' for sure.
 
  What I hate is deliberately introduced inconsistency in ebuild API's.
 
 What I hate is replicating bad practices just because someone else did
 that before. If I'm wrong, then please point me the relation between
 a particular buildsystem and patching.

Ideologically there's none, but practically build system may need patching in 
eclass to fit Gentoo needs. And it's better to do it officially in eclass 
src_prepare phase than hack around elsewhere.
Either provide all buildsystem related phases or none - I'm already tired of 
playing guess which phase from which eclass takes precedence when multiple 
inheritance is used game.

-- 
regards
MM


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] New eclass: scons.eclass

2010-08-24 Thread Michał Górny 
r4, ChangeLog:

3e30e1f Rename to scons-utils.eclass.
6477004 Remove exported phase functions.
41784fc Implement a cache in scons_clean_makeopts().
9b3ce5d Clarify doc on SCONSOPTS.
ac9f7ed Call scons_clean_makeopts() inline instead of exporting
SCONSOPTS.
ae6afd9 Fix SCONSOPTS check in escons().

-- 
Best regards,
Michał Górny

http://mgorny.alt.pl
xmpp:mgo...@jabber.ru


scons-utils.eclass
Description: Binary data
diff --git a/scons.eclass b/scons-utils.eclass
similarity index 85%
rename from scons.eclass
rename to scons-utils.eclass
index d29299c..bc91f96 100644
--- a/scons.eclass
+++ b/scons-utils.eclass
@@ -20,8 +20,8 @@
 # @ECLASS-VARIABLE: SCONSOPTS
 # @DESCRIPTION:
 # The default set of options to pass to scons. Similar to MAKEOPTS,
-# supposed to be set in make.conf. If unset, will be generated from
-# MAKEOPTS.
+# supposed to be set in make.conf. If unset, escons() will use cleaned
+# up MAKEOPTS instead.
 # @DEFAULT-UNSET
 
 # @ECLASS-VARIABLE: EXTRA_ESCONS
@@ -47,30 +47,6 @@ else
 	DEPEND=dev-util/scons
 fi
 
-# -- exported phase functions --
-
-case ${EAPI:-0} in
-	1|0) EXPORT_FUNCTIONS src_compile;;
-	*) EXPORT_FUNCTIONS src_configure src_compile;;
-esac
-
-# @FUNCTION: scons_src_configure
-# @DESCRIPTION:
-# A blank src_configure() for SCons packages not using explicit
-# configure phase.
-scons_src_configure() {
-	debug-print-function ${FUNCNAME} $...@}
-}
-
-# @FUNCTION: scons_src_compile
-# @DESCRIPTION:
-# The exported src_compile() implementation. Simply calls escons().
-scons_src_compile() {
-	debug-print-function ${FUNCNAME} $...@}
-
-	escons || die 'escons failed.'
-}
-
 # -- public functions --
 
 # @FUNCTION: escons
@@ -81,12 +57,8 @@ scons_src_compile() {
 escons() {
 	debug-print-function ${FUNCNAME} $...@}
 
-	# if SCONSOPTS are _unset_, create them from MAKEOPTS
-	if [[ -n ${SCONSOPTS+1} ]]; then
-		export SCONSOPTS=$(scons_clean_makeopts)
-	fi
-
-	set -- scons ${SCONSOPTS} ${EXTRA_ESCONS} $...@}
+	# if SCONSOPTS are _unset_, use cleaned MAKEOPTS
+	set -- scons ${SCONSOPTS-$(scons_clean_makeopts)} ${EXTRA_ESCONS} $...@}
 	echo $...@} 2
 	$...@}
 }
@@ -104,13 +76,23 @@ scons_clean_makeopts() {
 	debug-print-function ${FUNCNAME} $...@}
 
 	if [[ ${#} -eq 0 ]]; then
-		debug-print Using MAKEOPTS: ${MAKEOPTS}
+		debug-print Using MAKEOPTS: [${MAKEOPTS}]
 		set -- ${MAKEOPTS}
 	else
 		# unquote if necessary
 		set -- ${*}
 	fi
 
+	# empty MAKEOPTS give out empty SCONSOPTS
+	# thus, we do need to worry about the initial setup
+	if [[ ${*} = ${_SCONS_CACHE_MAKEOPTS} ]]; then
+		set -- ${_SCONS_CACHE_SCONSOPTS}
+		debug-print Cache hit: [${*}]
+		echo ${*}
+		return
+	fi
+	export _SCONS_CACHE_MAKEOPTS=${*}
+
 	while [[ ${#} -gt 0 ]]; do
 		case ${1} in
 			# clean, simple to check -- we like that
@@ -167,8 +149,10 @@ scons_clean_makeopts() {
 		shift
 	done
 
-	debug-print New SCONSOPTS: ${new_makeopts}
-	echo ${new_makeopts}
+	set -- ${new_makeopts}
+	export _SCONS_CACHE_SCONSOPTS=${*}
+	debug-print New SCONSOPTS: [${*}]
+	echo ${*}
 }
 
 # @FUNCTION: use_scons


signature.asc
Description: PGP signature

Re: [gentoo-dev] New eclass: scons.eclass

2010-08-24 Thread Mike Frysinger 
On Tuesday, August 24, 2010 14:40:56 Michał Górny wrote:
 3e30e1f Rename to scons-utils.eclass.

funny, i thought scons.eclass was appropriate.  but whatever.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] New eclass: scons.eclass

2010-08-24 Thread Michał Górny 
On Tue, 24 Aug 2010 17:30:32 -0400
Mike Frysinger vap...@gentoo.org wrote:

 On Tuesday, August 24, 2010 14:40:56 Michał Górny wrote:
  3e30e1f Rename to scons-utils.eclass.
 
 funny, i thought scons.eclass was appropriate.  but whatever.

Maciej complained about not exporting all ever possible buildsystem-
-unrelated functions like other non-utils-named eclasses tend to do.

-- 
Best regards,
Michał Górny

http://mgorny.alt.pl
xmpp:mgo...@jabber.ru


signature.asc
Description: PGP signature

Re: [gentoo-dev] New eclass: scons.eclass

2010-08-23 Thread Michał Górny 
On Sun, 22 Aug 2010 20:39:23 +0200
Michał Górny gen...@mgorny.alt.pl wrote:

The third revision, almost all suggestions applied. The ChangeLog:

151ddf2 Support passing a flag list to scons_clean_makeopts().
82a3ee7 Output the resulting flag list in scons_clean_makeopts()
instead of assigning it.
8062ec7 Provide a blank src_configure() for EAPI 2+.
33b4406 Drop default pkg_setup() -- no longer necessary.
44188e0 escons(): set SCONSOPTS implicitly if they are unset.
0f2ea92 Fix tests to use underscores in function names.
ccf1ef9 Introduce SCONSOPTS and use it instead of MAKEOPTS.
501ba41 Rename scons_use() to use_scons(), and the related vars.
681d73f Print the complete SCons command line in escons().
194e52e Use @DEFAULT-UNSET.
42aec9f Remove incorrect @CODE use.

Attaching the eclass r3 and a diff against r2.

-- 
Best regards,
Michał Górny

http://mgorny.alt.pl
xmpp:mgo...@jabber.ru
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: scons.eclass
# @MAINTAINER:
# gen...@mgorny.alt.pl
# @BLURB: helper functions to deal with SCons buildsystem
# @DESCRIPTION:
# This eclass provides a set of function to help developers sanely call
# dev-util/scons and pass parameters to it.

# -- public variables --

# @ECLASS-VARIABLE: SCONS_MIN_VERSION
# @DESCRIPTION:
# The minimal version of SCons required for the build to work.
# @DEFAULT-UNSET

# @ECLASS-VARIABLE: SCONSOPTS
# @DESCRIPTION:
# The default set of options to pass to scons. Similar to MAKEOPTS,
# supposed to be set in make.conf. If unset, will be generated from
# MAKEOPTS.
# @DEFAULT-UNSET

# @ECLASS-VARIABLE: EXTRA_ESCONS
# @DESCRIPTION:
# The additional parameters to pass to SCons whenever escons() is used.
# @DEFAULT-UNSET

# @ECLASS-VARIABLE: USE_SCONS_TRUE
# @DESCRIPTION:
# The default value for truth in scons-use() (1 by default).
: ${USE_SCONS_TRUE:=1}

# @ECLASS-VARIABLE: USE_SCONS_FALSE
# @DESCRIPTION:
# The default value for false in scons-use() (0 by default).
: ${USE_SCONS_FALSE:=0}

# -- ebuild variables setup --

if [[ -n ${SCONS_MIN_VERSION} ]]; then
	DEPEND==dev-util/scons-${SCONS_MIN_VERSION}
else
	DEPEND=dev-util/scons
fi

# -- exported phase functions --

case ${EAPI:-0} in
	1|0) EXPORT_FUNCTIONS src_compile;;
	*) EXPORT_FUNCTIONS src_configure src_compile;;
esac

# @FUNCTION: scons_src_configure
# @DESCRIPTION:
# A blank src_configure() for SCons packages not using explicit
# configure phase.
scons_src_configure() {
	debug-print-function ${FUNCNAME} $...@}
}

# @FUNCTION: scons_src_compile
# @DESCRIPTION:
# The exported src_compile() implementation. Simply calls escons().
scons_src_compile() {
	debug-print-function ${FUNCNAME} $...@}

	escons || die 'escons failed.'
}

# -- public functions --

# @FUNCTION: escons
# @USAGE: [scons-arg] ...
# @DESCRIPTION:
# Call scons, passing the supplied arguments, ${MAKEOPTS} and
# ${EXTRA_ESCONS}. Similar to emake.
escons() {
	debug-print-function ${FUNCNAME} $...@}

	# if SCONSOPTS are _unset_, create them from MAKEOPTS
	if [[ -n ${SCONSOPTS+1} ]]; then
		export SCONSOPTS=$(scons_clean_makeopts)
	fi

	set -- scons ${SCONSOPTS} ${EXTRA_ESCONS} $...@}
	echo $...@} 2
	$...@}
}

# @FUNCTION: scons_clean_makeopts
# @USAGE: [makeflags] [...]
# @DESCRIPTION:
# Strip the supplied makeflags (or ${MAKEOPTS} if called without
# an argument) of options not supported by SCons and make sure --jobs
# gets an argument. Output the resulting flag list (suitable
# for an assignment to SCONSOPTS).
scons_clean_makeopts() {
	local new_makeopts

	debug-print-function ${FUNCNAME} $...@}

	if [[ ${#} -eq 0 ]]; then
		debug-print Using MAKEOPTS: ${MAKEOPTS}
		set -- ${MAKEOPTS}
	else
		# unquote if necessary
		set -- ${*}
	fi

	while [[ ${#} -gt 0 ]]; do
		case ${1} in
			# clean, simple to check -- we like that
			--jobs=*|--keep-going)
new_makeopts=${new_makeopts+${new_makeopts} }${1}
;;
			# need to take a look at the next arg and guess
			--jobs)
if [[ ${#} -gt 1  ${2} =~ [0-9]+ ]]; then
	new_makeopts=${new_makeopts+${new_makeopts} }${1} ${2}
	shift
else
	# no value means no limit, let's pass a random int
	new_makeopts=${new_makeopts+${new_makeopts} }${1}=255
fi
;;
			# strip other long options
			--*)
;;
			# short option hell
			-*)
local str new_optstr
new_optstr=
str=${1#-}

while [[ -n ${str} ]]; do
	case ${str} in
		k*)
			new_optstr=${new_optstr}k
			;;
		# -j needs to come last
		j)
			if [[ ${#} -gt 1  ${2} =~ [0-9]+ ]]; then
new_optstr=${new_optstr}j ${2}
shift
			else
new_optstr=${new_optstr}j 255
			fi
			;;
		# otherwise, everything after -j is treated as an arg
		j*)
			new_optstr=${new_optstr}${str}
			break
			;;
	esac
	str=${str#?}
done

if [[ -n ${new_optstr} ]]; then
	new_makeopts=${new_makeopts+${new_makeopts} }-${new_optstr}
fi
;;
		esac
		shift

Re: [gentoo-dev] New eclass: scons.eclass

2010-08-23 Thread Mike Frysinger 
On Monday, August 23, 2010 12:24:54 Michał Górny wrote:
 The third revision, almost all suggestions applied. The ChangeLog:

if there are suggestions you've actively ignored, those should be noted

 44188e0 escons(): set SCONSOPTS implicitly if they are unset.
 ccf1ef9 Introduce SCONSOPTS and use it instead of MAKEOPTS.

i'm not sure caching the value and using it in between runs is a good idea.  
unless you also cache the thing you're caching and compare it to make sure 
your cache is no longer invalid.

i.e. export _SCONSOPTS_MAKEOPTS=${MAKEOPTS}, and then on every escons 
invocation, make sure ${MAKEOPTS} hasnt changed in which case you need to 
regenerate it.  or just avoid the cache altogether and leave SCONSOPTS as a 
hook specific to scons.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] New eclass: scons.eclass

2010-08-23 Thread Michał Górny 
On Mon, 23 Aug 2010 12:39:50 -0400
Mike Frysinger vap...@gentoo.org wrote:

 On Monday, August 23, 2010 12:24:54 Michał Górny wrote:
  The third revision, almost all suggestions applied. The ChangeLog:
 
 if there are suggestions you've actively ignored, those should be
 noted

I've replied to the specific suggestions but if you want, here's a
short summary:
- stripping ! from varname in use_scons() suggestion (I don't see a
  real point there as I replied you),
- src_prepare() calling base_src_prepare() (it is better to inherit
  base within the specific ebuild),
- src_install() calling base_src_install() (the base.eclass
  implementation calls make).

 i'm not sure caching the value and using it in between runs is a good
 idea. unless you also cache the thing you're caching and compare it
 to make sure your cache is no longer invalid.
 
 i.e. export _SCONSOPTS_MAKEOPTS=${MAKEOPTS}, and then on every escons 
 invocation, make sure ${MAKEOPTS} hasnt changed in which case you
 need to regenerate it.  or just avoid the cache altogether and leave
 SCONSOPTS as a hook specific to scons.

Can do, though I don't see a reason why anyone would mangle MAKEOPTS in
a middle of an ebuild using SCons.

PS Why don't your mails contain 'Reply-To' header like others do?

-- 
Best regards,
Michał Górny

http://mgorny.alt.pl
xmpp:mgo...@jabber.ru


signature.asc
Description: PGP signature

Re: [gentoo-dev] New eclass: scons.eclass

2010-08-23 Thread Mike Frysinger 
On Monday, August 23, 2010 13:16:38 Michał Górny wrote:
 On Mon, 23 Aug 2010 12:39:50 -0400 Mike Frysinger wrote:
  i'm not sure caching the value and using it in between runs is a good
  idea. unless you also cache the thing you're caching and compare it
  to make sure your cache is no longer invalid.
  
  i.e. export _SCONSOPTS_MAKEOPTS=${MAKEOPTS}, and then on every escons
  invocation, make sure ${MAKEOPTS} hasnt changed in which case you
  need to regenerate it.  or just avoid the cache altogether and leave
  SCONSOPTS as a hook specific to scons.
 
 Can do, though I don't see a reason why anyone would mangle MAKEOPTS in
 a middle of an ebuild using SCons.

i agree, but you might as have it work properly in all cases instead of 
flaking out randomly on ebuild authors.  i think someone told me something 
similar recently in a bug report about cvs.eclass ..

 PS Why don't your mails contain 'Reply-To' header like others do?

you can subscribe to a list but have delivery turned off
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] New eclass: scons.eclass

2010-08-23 Thread Michał Górny 
On Mon, 23 Aug 2010 16:22:35 -0400
Mike Frysinger vap...@gentoo.org wrote:

 On Monday, August 23, 2010 13:16:38 Michał Górny wrote:
  On Mon, 23 Aug 2010 12:39:50 -0400 Mike Frysinger wrote:
   i'm not sure caching the value and using it in between runs is a
   good idea. unless you also cache the thing you're caching and
   compare it to make sure your cache is no longer invalid.
   
   i.e. export _SCONSOPTS_MAKEOPTS=${MAKEOPTS}, and then on every
   escons invocation, make sure ${MAKEOPTS} hasnt changed in which
   case you need to regenerate it.  or just avoid the cache
   altogether and leave SCONSOPTS as a hook specific to scons.
  
  Can do, though I don't see a reason why anyone would mangle
  MAKEOPTS in a middle of an ebuild using SCons.
 
 i agree, but you might as have it work properly in all cases instead
 of flaking out randomly on ebuild authors.

We're hitting another corner case then. What if user modifies SCONSOPTS
in the middle of an ebuild? We could export another variable keeping
resulting SCONSOPTS and comparing it with the current SCONSOPTS -- but
what if the ebuild author randomly hit the same flags that resulted
from MAKEOPTS-SCONSOPTS conversion (and changed MAKEOPTS at the same
time)?

If we consider it like that, we end up with the idea that re-generating
SCONSOPTS every time escons() is called is the only feasible solution
-- but I don't really think it is worth to waste the time considering
it.

-- 
Best regards,
Michał Górny

http://mgorny.alt.pl
xmpp:mgo...@jabber.ru


signature.asc
Description: PGP signature

Re: [gentoo-dev] New eclass: scons.eclass

2010-08-23 Thread Mike Frysinger 
On Monday, August 23, 2010 19:02:21 Michał Górny wrote:
 On Mon, 23 Aug 2010 16:22:35 -0400 Mike Frysinger wrote:
  On Monday, August 23, 2010 13:16:38 Michał Górny wrote:
   On Mon, 23 Aug 2010 12:39:50 -0400 Mike Frysinger wrote:
i'm not sure caching the value and using it in between runs is a
good idea. unless you also cache the thing you're caching and
compare it to make sure your cache is no longer invalid.

i.e. export _SCONSOPTS_MAKEOPTS=${MAKEOPTS}, and then on every
escons invocation, make sure ${MAKEOPTS} hasnt changed in which
case you need to regenerate it.  or just avoid the cache
altogether and leave SCONSOPTS as a hook specific to scons.
   
   Can do, though I don't see a reason why anyone would mangle
   MAKEOPTS in a middle of an ebuild using SCons.
  
  i agree, but you might as have it work properly in all cases instead
  of flaking out randomly on ebuild authors.
 
 We're hitting another corner case then. What if user modifies SCONSOPTS
 in the middle of an ebuild? We could export another variable keeping
 resulting SCONSOPTS and comparing it with the current SCONSOPTS -- but
 what if the ebuild author randomly hit the same flags that resulted
 from MAKEOPTS-SCONSOPTS conversion (and changed MAKEOPTS at the same
 time)?
 
 If we consider it like that, we end up with the idea that re-generating
 SCONSOPTS every time escons() is called is the only feasible solution
 -- but I don't really think it is worth to waste the time considering
 it.

then keep it simple and separate:
escons() {
debug-print-function ${FUNCNAME} $...@}

set -- scons $(scons_clean_makeopts) ${SCONSOPTS} ${EXTRA_ESCONS} 
$...@}
echo $...@} 2
$...@}
}

now you dont have to worry about changes between invocations and the developer 
has a clear path -- if they need to force a serial build for example, they can 
either append MAKEOPTS, SCONSOPTS, or pass it straight to escons.  no cache 
confusion or desync between the vars.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] New eclass: scons.eclass

2010-08-22 Thread Alex Alexander 
On Sun, Aug 22, 2010 at 12:04:52PM +0200, Michał Górny wrote:
 Hello,
 
 As per bug #333911, I'm working on a new eclass, providing some basic
 functions common to most of the ebuilds using the SCons build system.
 
 [...]
 
 I'm attaching the eclass draft (the same which is attached to bug
 #333911), and inlining a simple use example below:
 
 #v+
 inherit scons
 
 # ...
 
 pkg_setup() {
   scons-clean-makeopts
 }
 
 src_compile() {
   scons \
   $(scons-use unicode) \
   $(scons-use gnutls ssl gnutls openssl) \
   ${MAKEOPTS} || die
   # expands into:
   # scons unicode={1|0} ssl={gnutls|openssl} -jN || die
 }
 #v-

Looks nice :)

You could avoid having to define pkg_setup in every ebuild by defining a
default one in your eclass:

--- scons.eclass.old2010-08-22 13:11:57.0 +0300
+++ scons.eclass2010-08-22 13:15:57.0 +0300
@@ -39,6 +39,15 @@
DEPEND=dev-util/scons
 fi
 
+# -- phase functions --
+
+# @FUNCTION: scons_pkg_setup
+# @DESCRIPTION:
+# default pkg_setup, runs scons-clean-makeopts
+scons_pkg_setup() {
+   scons-clean-makeopts
+}
+
 # -- public functions --
 
 # @FUNCTION: scons-clean-makeopts
@@ -185,3 +194,5 @@
_scons-clean-makeopts-perform-test '-j2 HOME=/tmp' '-j2'
_scons-clean-makeopts-perform-test '--jobs funnystuff -k' --jobs=${jc} 
-k
 }
+
+EXPORT_FUNCTIONS pkg_setup

 -- 
 Best regards,
 Michał Górny
 
 http://mgorny.alt.pl
 xmpp:mgo...@jabber.ru

-- 
Alex Alexander -=- wired
Gentoo Linux Developer -=- Council / Qt / Chromium / KDE / more
www.linuxized.com


pgp0A6fSdvEeq.pgp
Description: PGP signature

Re: [gentoo-dev] New eclass: scons.eclass

2010-08-22 Thread David Leverton 
2010/8/22 Michał Górny gen...@mgorny.alt.pl:
 src_compile() {
        scons \
                $(scons-use unicode) \
                $(scons-use gnutls ssl gnutls openssl) \
                ${MAKEOPTS} || die
        # expands into:
        # scons unicode={1|0} ssl={gnutls|openssl} -jN || die
 }

It might be slightly nicer to have an escons function that adds the
modified MAKEOPTS to the command line and calls die by itself.
Besides making it easier to use, that would provide a single place to
add additional functionality (perhaps an EXTRA_ESCONS user variable
analogous to EXTRA_ECONF, for example).

Re: [gentoo-dev] New eclass: scons.eclass

2010-08-22 Thread Michał Górny 
On Sun, 22 Aug 2010 13:26:18 +0300
Alex Alexander wi...@gentoo.org wrote:

 You could avoid having to define pkg_setup in every ebuild by
 defining a default one in your eclass:

Yeah, I am considering that. I am considering adding a default
src_compile() too.

-- 
Best regards,
Michał Górny

http://mgorny.alt.pl
xmpp:mgo...@jabber.ru


signature.asc
Description: PGP signature

Re: [gentoo-dev] New eclass: scons.eclass

2010-08-22 Thread Michał Górny 
On Sun, 22 Aug 2010 12:03:10 +0100
David Leverton levert...@googlemail.com wrote:

 2010/8/22 Michał Górny gen...@mgorny.alt.pl:
  src_compile() {
         scons \
                 $(scons-use unicode) \
                 $(scons-use gnutls ssl gnutls openssl) \
                 ${MAKEOPTS} || die
         # expands into:
         # scons unicode={1|0} ssl={gnutls|openssl} -jN || die
  }
 
 It might be slightly nicer to have an escons function that adds the
 modified MAKEOPTS to the command line and calls die by itself.
 Besides making it easier to use, that would provide a single place to
 add additional functionality (perhaps an EXTRA_ESCONS user variable
 analogous to EXTRA_ECONF, for example).

I may add an escons() function but I think the MAKEOPTS mangling still
matches pkg_setup() better. And I don't like the idea of keeping a
MAKEOPTS_ALREADY_MANGLED kind of variable to avoid re-mangling on next
call to escons().

-- 
Best regards,
Michał Górny

http://mgorny.alt.pl
xmpp:mgo...@jabber.ru


signature.asc
Description: PGP signature