* Re: [gentoo-dev] Re: New eclass: scons.eclass
2010-08-22 18:39 ` [gentoo-dev] " Michał Górny
@ 2010-08-22 20:44 ` Luca Barbato
2010-08-22 21:03 ` Maciej Mrozowski
` (3 subsequent siblings)
4 siblings, 0 replies; 34+ messages in thread
From: Luca Barbato @ 2010-08-22 20:44 UTC (permalink / raw
To: gentoo-dev; +Cc: Michał Górny
On 08/22/2010 08:39 PM, Michał Górny wrote:
> Here goes the second revision. A short changelog:
>
> 83678d1 Export a default pkg_setup() and src_compile().
> 7f9b565 Introduce escons() function (similar to emake).
> 19b7e14 Use underscores instead of dashes in function names.
>
> Attaching both the new rev and a diff against the first one.
What about having a SCONSOPTS and leave MAKEOPTS unmangled?
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: New eclass: scons.eclass
2010-08-22 18:39 ` [gentoo-dev] " Michał Górny
2010-08-22 20:44 ` Luca Barbato
@ 2010-08-22 21:03 ` Maciej Mrozowski
2010-08-23 15:11 ` Michał Górny
2010-08-22 21:06 ` [gentoo-dev] " Mike Frysinger
` (2 subsequent siblings)
4 siblings, 1 reply; 34+ messages in thread
From: Maciej Mrozowski @ 2010-08-22 21:03 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: Text/Plain, Size: 929 bytes --]
On Sunday 22 of August 2010 20:39:23 Michał Górny wrote:
> Here goes the second revision. A short changelog:
>
> 83678d1 Export a default pkg_setup() and src_compile().
> 7f9b565 Introduce escons() function (similar to emake).
> 19b7e14 Use underscores instead of dashes in function names.
>
> Attaching both the new rev and a diff against the first one.
I'd suggest providing all src_* phases except src_unpack.
Even src_prepare that calls base_src_prepare - to get PATCHES and epatch_user
support - for simplicity requiring EAPI-2 as providing src_unpack in
buildsystem eclasses is a bad design (like providing src_prepare in scm
eclasses - this one is yet to be fixed).
Also calling base_src_install in scons_src_install if possible would be nice
(DOCS, HTML_DOCS support) - to make it resemble cmake-utils, autotools-utils,
and a bit of distutils, qt4-edge and gnome2 eclasses.
--
regards
MM
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: New eclass: scons.eclass
2010-08-22 21:03 ` Maciej Mrozowski
@ 2010-08-23 15:11 ` Michał Górny
2010-08-23 17:36 ` Maciej Mrozowski
0 siblings, 1 reply; 34+ messages in thread
From: Michał Górny @ 2010-08-23 15:11 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]
On Sun, 22 Aug 2010 23:03:44 +0200
Maciej Mrozowski <reavertm@gmail.com> wrote:
> I'd suggest providing all src_* phases except src_unpack.
Providing a blank src_configure() would be fine but...
> Even src_prepare that calls base_src_prepare - to get PATCHES and
> epatch_user support - for simplicity requiring EAPI-2 as providing
> src_unpack in buildsystem eclasses is a bad design (like providing
> src_prepare in scm eclasses - this one is yet to be fixed).
Why would I do that? If an ebuild needs to use base_src_prepare(), why
can't it simply inherit the base eclass? Nothing buildsystem-specific
needs to be done in src_prepare() here.
And requiring EAPI=2 is even more pointless as SCons doesn't mostly
distinguish between 'configure' and 'build' phases.
> Also calling base_src_install in scons_src_install if possible would
> be nice (DOCS, HTML_DOCS support) - to make it resemble cmake-utils,
> autotools-utils, and a bit of distutils, qt4-edge and gnome2 eclasses.
Even more pointless. Although we can assume many of the SConstruct
files use the name 'install' for their 'install' target, we can't do
that for 'DESTDIR' or how a particular project calls it. Not to mention
some don't provide such a thing at all. Every SCons-based ebuild should
redefine src_install().
--
Best regards,
Michał Górny
<http://mgorny.alt.pl>
<xmpp:mgorny@jabber.ru>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: New eclass: scons.eclass
2010-08-23 15:11 ` Michał Górny
@ 2010-08-23 17:36 ` Maciej Mrozowski
2010-08-24 8:30 ` [gentoo-dev] " Michał Górny
0 siblings, 1 reply; 34+ messages in thread
From: Maciej Mrozowski @ 2010-08-23 17:36 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: Text/Plain, Size: 2314 bytes --]
On Monday 23 of August 2010 17:11:47 Michał Górny wrote:
> On Sun, 22 Aug 2010 23:03:44 +0200
>
> Maciej Mrozowski <reavertm@gmail.com> wrote:
> > I'd suggest providing all src_* phases except src_unpack.
>
> Providing a blank src_configure() would be fine but...
>
> > Even src_prepare that calls base_src_prepare - to get PATCHES and
> > epatch_user support - for simplicity requiring EAPI-2 as providing
> > src_unpack in buildsystem eclasses is a bad design (like providing
> > src_prepare in scm eclasses - this one is yet to be fixed).
>
> Why would I do that? If an ebuild needs to use base_src_prepare(), why
> can't it simply inherit the base eclass? Nothing buildsystem-specific
> needs to be done in src_prepare() here.
> And requiring EAPI=2 is even more pointless as SCons doesn't mostly
> distinguish between 'configure' and 'build' phases.
Because if you're to provide src_prepare, for EAPI<2 you need to provide
src_unpack as well but it's wrong in buildsystem eclasses as I already pointed
out (since src_unpack:EAPI1 -> src_unpack:EAPI2 + src_prepare:EAPI2), and
requiring EAPI-2 allows you to avoid it.
If you don't care for PATCHES or user_patches and hence compliance with other
buildsystem eclasses, feel free.
> > Also calling base_src_install in scons_src_install if possible would
> > be nice (DOCS, HTML_DOCS support) - to make it resemble cmake-utils,
> > autotools-utils, and a bit of distutils, qt4-edge and gnome2 eclasses.
>
> Even more pointless. Although we can assume many of the SConstruct
> files use the name 'install' for their 'install' target, we can't do
> that for 'DESTDIR' or how a particular project calls it. Not to mention
> some don't provide such a thing at all. Every SCons-based ebuild should
> redefine src_install().
Like I said, if you don't care for consistency with the rest, feel free to
ignore.
If SCons is unpredictable, then don't provide *any* phases and only functions
and rename it to scons-utils to match its purpose (we're quite likely planning
to rename cmake-utils.eclass to cmake.eclass for said consistency,
unfortunately it was introduced in first place with such name and provided
phases).
What I hate is deliberately introduced inconsistency in ebuild API's.
--
regards
MM
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] New eclass: scons.eclass
2010-08-23 17:36 ` Maciej Mrozowski
@ 2010-08-24 8:30 ` Michał Górny
2010-08-24 17:52 ` Maciej Mrozowski
0 siblings, 1 reply; 34+ messages in thread
From: Michał Górny @ 2010-08-24 8:30 UTC (permalink / raw
To: gentoo-dev; +Cc: reavertm
[-- Attachment #1: Type: text/plain, Size: 761 bytes --]
On Mon, 23 Aug 2010 19:36:50 +0200
Maciej Mrozowski <reavertm@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:mgorny@jabber.ru>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] New eclass: scons.eclass
2010-08-24 8:30 ` [gentoo-dev] " Michał Górny
@ 2010-08-24 17:52 ` Maciej Mrozowski
0 siblings, 0 replies; 34+ messages in thread
From: Maciej Mrozowski @ 2010-08-24 17:52 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: Text/Plain, Size: 1173 bytes --]
On Tuesday 24 of August 2010 10:30:12 Michał Górny wrote:
> On Mon, 23 Aug 2010 19:36:50 +0200
>
> Maciej Mrozowski <reavertm@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
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: New eclass: scons.eclass
2010-08-22 18:39 ` [gentoo-dev] " Michał Górny
2010-08-22 20:44 ` Luca Barbato
2010-08-22 21:03 ` Maciej Mrozowski
@ 2010-08-22 21:06 ` Mike Frysinger
2010-08-22 21:10 ` Tomáš Chvátal
[not found] ` <20100823174249.5eb1a865@pomiocik.lan>
2010-08-23 16:24 ` [gentoo-dev] " Michał Górny
2010-08-24 18:40 ` Michał Górny
4 siblings, 2 replies; 34+ messages in thread
From: Mike Frysinger @ 2010-08-22 21:06 UTC (permalink / raw
To: gentoo-dev; +Cc: Michał Górny
[-- Attachment #1: Type: Text/Plain, Size: 1049 bytes --]
> # @CODE
> # Michał Górny <gentoo@mgorny.alt.pl>
> # @CODE
this is not what @code is designed for. punt it.
> : ${SCONS_MIN_VERSION}
useless statement. punt it.
> : ${EXTRA_ESCONS:=}
replace with @DEFAULT_UNSET
> scons ${MAKEOPTS} ${EXTRA_ESCONS} "${@}"
this should be echoed just like emake and econf and other things do now.
set -- scons $(scons_makeopts) ${EXTRA_ESCONS} "$@"
echo "$@"
"$@"
> scons_clean_makeopts
better to do this on the fly and inline. otherwise you prevent the ebuild
from being used in conjunction with standard make builds.
i.e. have it parse ${MAKEOPTS} and echo the result, then change escons to call
it all by itself. this isnt something ebuild maintainers should be bothered
with. `escons` should be sufficient.
> scons_use()
keep the use_xxx style ... so rename it to "use_scons()"
> local varname=${2:-${flag}}
should be stripping possible leading ! so that people can do `use_scons !foo
moo` just like they can today with `use_with $foo moo`
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: New eclass: scons.eclass
2010-08-22 21:06 ` [gentoo-dev] " Mike Frysinger
@ 2010-08-22 21:10 ` Tomáš Chvátal
2010-08-22 21:18 ` Mike Frysinger
[not found] ` <20100823174249.5eb1a865@pomiocik.lan>
1 sibling, 1 reply; 34+ messages in thread
From: Tomáš Chvátal @ 2010-08-22 21:10 UTC (permalink / raw
To: gentoo-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dne 22.8.2010 23:06, Mike Frysinger napsal(a):
>
>> scons_use()
>
> keep the use_xxx style ... so rename it to "use_scons()"
>
>> local varname=${2:-${flag}}
>
> should be stripping possible leading ! so that people can do `use_scons !foo
> moo` just like they can today with `use_with $foo moo`
> -mike
Hmm we use
cmake-utils_use_*
i think use_cmake-utils-*
also if renamed to cmake_use-* it would look more sane than use_cmake-*
but if we make agreement other way we can replace it in cmake utils
quite easily :)
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxxkkgACgkQHB6c3gNBRYdOGQCgsp5TP/cfE4ijE7lYuC14XwX8
VNwAoLEXUuAR2djw7j+dUZ6XrvxnkaLI
=ta36
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: New eclass: scons.eclass
2010-08-22 21:10 ` Tomáš Chvátal
@ 2010-08-22 21:18 ` Mike Frysinger
2010-08-22 21:32 ` Tomáš Chvátal
0 siblings, 1 reply; 34+ messages in thread
From: Mike Frysinger @ 2010-08-22 21:18 UTC (permalink / raw
To: gentoo-dev; +Cc: Tomáš Chvátal
[-- Attachment #1: Type: Text/Plain, Size: 563 bytes --]
On Sunday, August 22, 2010 17:10:32 Tomáš Chvátal wrote:
> Dne 22.8.2010 23:06, Mike Frysinger napsal(a):
> >> scons_use()
> >
> > keep the use_xxx style ... so rename it to "use_scons()"
>
> Hmm we use
> cmake-utils_use_*
>
> i think use_cmake-utils-*
>
> also if renamed to cmake_use-* it would look more sane than use_cmake-*
>
> but if we make agreement other way we can replace it in cmake utils
> quite easily :)
changing eclass style to match the older-than-PMS style sounds more feasible.
so i'd go with use_cmake-xxx.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: New eclass: scons.eclass
2010-08-22 21:18 ` Mike Frysinger
@ 2010-08-22 21:32 ` Tomáš Chvátal
2010-08-22 22:03 ` Mike Frysinger
0 siblings, 1 reply; 34+ messages in thread
From: Tomáš Chvátal @ 2010-08-22 21:32 UTC (permalink / raw
To: gentoo-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dne 22.8.2010 23:18, Mike Frysinger napsal(a):
> On Sunday, August 22, 2010 17:10:32 Tomáš Chvátal wrote:
>> Dne 22.8.2010 23:06, Mike Frysinger napsal(a):
>>>> scons_use()
>>>
>>> keep the use_xxx style ... so rename it to "use_scons()"
>>
>> Hmm we use
>> cmake-utils_use_*
>>
>> i think use_cmake-utils-*
>>
>> also if renamed to cmake_use-* it would look more sane than use_cmake-*
>>
>> but if we make agreement other way we can replace it in cmake utils
>> quite easily :)
>
> changing eclass style to match the older-than-PMS style sounds more feasible.
> so i'd go with use_cmake-xxx.
> -mike
Do we have some poll capabilites only for devs? Something on forums?
We can do either way and provide backcompat -> not so hard :) So i would
leave decision to the peepz.
I dont care whether i use cmake-utils_use_enable or use_cmake_enable :)
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxxl1sACgkQHB6c3gNBRYcxqQCcDkf2REdWYuLUy1/e5OsgUJzd
EsQAnihzaLyq+Jgf+g6kR0O8Y9kDw5Zh
=wjUC
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: New eclass: scons.eclass
2010-08-22 21:32 ` Tomáš Chvátal
@ 2010-08-22 22:03 ` Mike Frysinger
0 siblings, 0 replies; 34+ messages in thread
From: Mike Frysinger @ 2010-08-22 22:03 UTC (permalink / raw
To: gentoo-dev; +Cc: Tomáš Chvátal
[-- Attachment #1: Type: Text/Plain, Size: 1493 bytes --]
On Sunday, August 22, 2010 17:32:11 Tomáš Chvátal wrote:
> Dne 22.8.2010 23:18, Mike Frysinger napsal(a):
> > On Sunday, August 22, 2010 17:10:32 Tomáš Chvátal wrote:
> >> Dne 22.8.2010 23:06, Mike Frysinger napsal(a):
> >>>> scons_use()
> >>>
> >>> keep the use_xxx style ... so rename it to "use_scons()"
> >>
> >> Hmm we use
> >> cmake-utils_use_*
> >>
> >> i think use_cmake-utils-*
> >>
> >> also if renamed to cmake_use-* it would look more sane than use_cmake-*
> >>
> >> but if we make agreement other way we can replace it in cmake utils
> >> quite easily :)
> >
> > changing eclass style to match the older-than-PMS style sounds more
> > feasible. so i'd go with use_cmake-xxx.
>
> Do we have some poll capabilites only for devs? Something on forums?
i think we only have the forums
> We can do either way and provide backcompat -> not so hard :) So i would
> leave decision to the peepz.
>
> I dont care whether i use cmake-utils_use_enable or use_cmake_enable :)
so we're clear, lemme phrase it this way: use_enable/use_with/use_xxx isnt
changing. whether you choose to rename the cmake eclasses to follow the
existing standard is up to you. personally, i think "use_cmake_enable" makes
the most sense (or dare i suggest "use_enable_cmake" ...).
transitional backwards compat shouldnt be hard. ewarn should dump to stderr
which means you should be able to use it in existing functions without
breaking people.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
[parent not found: <20100823174249.5eb1a865@pomiocik.lan>]
* Re: [gentoo-dev] Re: New eclass: scons.eclass
[not found] ` <20100823174249.5eb1a865@pomiocik.lan>
@ 2010-08-24 21:28 ` Mike Frysinger
0 siblings, 0 replies; 34+ messages in thread
From: Mike Frysinger @ 2010-08-24 21:28 UTC (permalink / raw
To: Michał Górny, gentoo-dev
[-- Attachment #1: Type: Text/Plain, Size: 955 bytes --]
On Monday, August 23, 2010 11:42:49 Michał Górny wrote:
> On Sun, 22 Aug 2010 17:06:22 -0400 Mike Frysinger wrote:
> > > local varname=${2:-${flag}}
> >
> > should be stripping possible leading ! so that people can do
> > `use_scons !foo moo` just like they can today with `use_with $foo moo`
>
> Could you explain that better? Calling 'use_scons !foo moo' would cause
> varname to contain 'moo' anyway.
yeah, in that case it wouldnt matter
> If you meant calling just 'use_scons !foo' instead, I can do that but
> not sure if it'd be really useful. I guess packages don't tend to use
> some kind reverse logic for booleans, and would rather have
> the particular var prefixed by 'NO' or something like that then.
whether the upstream logic should be fixed is something to address there. the
extended `use_xxx` interfaces should support all the underlying features of
`use` and work just as well as the existing ones.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] New eclass: scons.eclass
2010-08-22 18:39 ` [gentoo-dev] " Michał Górny
` (2 preceding siblings ...)
2010-08-22 21:06 ` [gentoo-dev] " Mike Frysinger
@ 2010-08-23 16:24 ` Michał Górny
2010-08-23 16:39 ` Mike Frysinger
2010-08-24 18:40 ` Michał Górny
4 siblings, 1 reply; 34+ messages in thread
From: Michał Górny @ 2010-08-23 16:24 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1.1: Type: text/plain, Size: 935 bytes --]
On Sun, 22 Aug 2010 20:39:23 +0200
Michał Górny <gentoo@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:mgorny@jabber.ru>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: scons.eclass --]
[-- Type: text/x-shellscript, Size: 6809 bytes --]
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: scons.eclass
# @MAINTAINER:
# gentoo@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
done
debug-print "New SCONSOPTS: ${new_makeopts}"
echo ${new_makeopts}
}
# @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#!}}
local vartrue=${3:-${USE_SCONS_TRUE}}
local varfalse=${4:-${USE_SCONS_FALSE}}
debug-print-function ${FUNCNAME} "${@}"
if [[ ${#} -eq 0 ]]; then
eerror "Usage: scons-use <use-flag> [var-name] [var-opt-true] [var-opt-false]"
die 'scons-use(): not enough arguments'
fi
if use "${flag}"; then
echo "${varname}=${vartrue}"
else
echo "${varname}=${varfalse}"
fi
}
# -- self-tests --
_scons_clean_makeopts_perform_test() {
local sconsopts=$(scons_clean_makeopts ${1})
if [[ ${sconsopts} != ${2-${1}} ]]; then
cat >&2 <<_EOF_
Self-test failed:
Input string: ${1}
Output string: ${sconsopts}
Expected: ${2-${1}}
_EOF_
fi
}
# Perform a self-test on scons-clean-makeopts.
_scons_clean_makeopts_tests() {
# jobcount expected for non-specified state
local jc=255
# sane MAKEOPTS
_scons_clean_makeopts_perform_test '--jobs=14 -k'
_scons_clean_makeopts_perform_test '--jobs=14 -k'
_scons_clean_makeopts_perform_test '--jobs 15 -k'
_scons_clean_makeopts_perform_test '--jobs=16 --keep-going'
_scons_clean_makeopts_perform_test '-j17 --keep-going'
_scons_clean_makeopts_perform_test '-j 18 --keep-going'
# needing cleaning
_scons_clean_makeopts_perform_test '--jobs -k' "--jobs=${jc} -k"
_scons_clean_makeopts_perform_test '--jobs --keep-going' "--jobs=${jc} --keep-going"
_scons_clean_makeopts_perform_test '-kj' "-kj ${jc}"
# broken by definition (but passed as it breaks make as well)
_scons_clean_makeopts_perform_test '-jk'
_scons_clean_makeopts_perform_test '--jobs=randum'
_scons_clean_makeopts_perform_test '-kjrandum'
# needing stripping
_scons_clean_makeopts_perform_test '--load-average=25 -kj16' '-kj16'
_scons_clean_makeopts_perform_test '--load-average 25 -k -j17' '-k -j17'
_scons_clean_makeopts_perform_test '-j2 HOME=/tmp' '-j2'
_scons_clean_makeopts_perform_test '--jobs funnystuff -k' "--jobs=${jc} -k"
}
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.3: scons.eclass.diff --]
[-- Type: text/x-patch, Size: 7279 bytes --]
diff --git a/scons.eclass b/scons.eclass
index 8321ee0..d29299c 100644
--- a/scons.eclass
+++ b/scons.eclass
@@ -5,10 +5,6 @@
# @ECLASS: scons.eclass
# @MAINTAINER:
# gentoo@mgorny.alt.pl
-#
-# @CODE
-# Michał Górny <gentoo@mgorny.alt.pl>
-# @CODE
# @BLURB: helper functions to deal with SCons buildsystem
# @DESCRIPTION:
# This eclass provides a set of function to help developers sanely call
@@ -19,22 +15,29 @@
# @ECLASS-VARIABLE: SCONS_MIN_VERSION
# @DESCRIPTION:
# The minimal version of SCons required for the build to work.
-: ${SCONS_MIN_VERSION}
+# @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.
-: ${EXTRA_ESCONS:=}
+# @DEFAULT-UNSET
-# @ECLASS-VARIABLE: SCONS_USE_TRUE
+# @ECLASS-VARIABLE: USE_SCONS_TRUE
# @DESCRIPTION:
# The default value for truth in scons-use() (1 by default).
-: ${SCONS_USE_TRUE:=1}
+: ${USE_SCONS_TRUE:=1}
-# @ECLASS-VARIABLE: SCONS_USE_FALSE
+# @ECLASS-VARIABLE: USE_SCONS_FALSE
# @DESCRIPTION:
# The default value for false in scons-use() (0 by default).
-: ${SCONS_USE_FALSE:=0}
+: ${USE_SCONS_FALSE:=0}
# -- ebuild variables setup --
@@ -46,16 +49,17 @@ fi
# -- exported phase functions --
-EXPORT_FUNCTIONS pkg_setup src_compile
+case "${EAPI:-0}" in
+ 1|0) EXPORT_FUNCTIONS src_compile;;
+ *) EXPORT_FUNCTIONS src_configure src_compile;;
+esac
-# @FUNCTION: scons_pkg_setup
+# @FUNCTION: scons_src_configure
# @DESCRIPTION:
-# The exported pkg_setup() implementation. Calls scons_clean_makeopts()
-# to get a sane MAKEOPTS.
-scons_pkg_setup() {
+# A blank src_configure() for SCons packages not using explicit
+# configure phase.
+scons_src_configure() {
debug-print-function ${FUNCNAME} "${@}"
-
- scons_clean_makeopts
}
# @FUNCTION: scons_src_compile
@@ -76,21 +80,37 @@ scons_src_compile() {
# ${EXTRA_ESCONS}. Similar to emake.
escons() {
debug-print-function ${FUNCNAME} "${@}"
- debug-print scons ${MAKEOPTS} ${EXTRA_ESCONS} "${@}"
- scons ${MAKEOPTS} ${EXTRA_ESCONS} "${@}"
+ # 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 MAKEOPTS of options not supported by SCons and make sure --jobs
-# gets an argument.
+# 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} "${@}"
- set -- ${MAKEOPTS}
+ 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
@@ -147,11 +167,11 @@ scons_clean_makeopts() {
shift
done
- MAKEOPTS=${new_makeopts}
- export MAKEOPTS
+ debug-print "New SCONSOPTS: ${new_makeopts}"
+ echo ${new_makeopts}
}
-# @FUNCTION: scons_use
+# @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.
@@ -159,13 +179,13 @@ scons_clean_makeopts() {
# <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, SCONS_USE_TRUE
-# or SCONS_USE_FALSE will be used instead.
-scons_use() {
+# 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}}
- local vartrue=${3:-${SCONS_USE_TRUE}}
- local varfalse=${4:-${SCONS_USE_FALSE}}
+ local varname=${2:-${flag#!}}
+ local vartrue=${3:-${USE_SCONS_TRUE}}
+ local varfalse=${4:-${USE_SCONS_FALSE}}
debug-print-function ${FUNCNAME} "${@}"
@@ -183,45 +203,45 @@ scons_use() {
# -- self-tests --
-_scons-clean-makeopts-perform-test() {
- MAKEOPTS=${1}
- scons-clean-makeopts
- if [[ ${MAKEOPTS} != ${2-${1}} ]]; then
+_scons_clean_makeopts_perform_test() {
+ local sconsopts=$(scons_clean_makeopts ${1})
+
+ if [[ ${sconsopts} != ${2-${1}} ]]; then
cat >&2 <<_EOF_
Self-test failed:
Input string: ${1}
- Output string: ${MAKEOPTS}
+ Output string: ${sconsopts}
Expected: ${2-${1}}
_EOF_
fi
}
# Perform a self-test on scons-clean-makeopts.
-_scons-clean-makeopts-tests() {
+_scons_clean_makeopts_tests() {
# jobcount expected for non-specified state
local jc=255
# sane MAKEOPTS
- _scons-clean-makeopts-perform-test '--jobs=14 -k'
- _scons-clean-makeopts-perform-test '--jobs=14 -k'
- _scons-clean-makeopts-perform-test '--jobs 15 -k'
- _scons-clean-makeopts-perform-test '--jobs=16 --keep-going'
- _scons-clean-makeopts-perform-test '-j17 --keep-going'
- _scons-clean-makeopts-perform-test '-j 18 --keep-going'
+ _scons_clean_makeopts_perform_test '--jobs=14 -k'
+ _scons_clean_makeopts_perform_test '--jobs=14 -k'
+ _scons_clean_makeopts_perform_test '--jobs 15 -k'
+ _scons_clean_makeopts_perform_test '--jobs=16 --keep-going'
+ _scons_clean_makeopts_perform_test '-j17 --keep-going'
+ _scons_clean_makeopts_perform_test '-j 18 --keep-going'
# needing cleaning
- _scons-clean-makeopts-perform-test '--jobs -k' "--jobs=${jc} -k"
- _scons-clean-makeopts-perform-test '--jobs --keep-going' "--jobs=${jc} --keep-going"
- _scons-clean-makeopts-perform-test '-kj' "-kj ${jc}"
+ _scons_clean_makeopts_perform_test '--jobs -k' "--jobs=${jc} -k"
+ _scons_clean_makeopts_perform_test '--jobs --keep-going' "--jobs=${jc} --keep-going"
+ _scons_clean_makeopts_perform_test '-kj' "-kj ${jc}"
# broken by definition (but passed as it breaks make as well)
- _scons-clean-makeopts-perform-test '-jk'
- _scons-clean-makeopts-perform-test '--jobs=randum'
- _scons-clean-makeopts-perform-test '-kjrandum'
+ _scons_clean_makeopts_perform_test '-jk'
+ _scons_clean_makeopts_perform_test '--jobs=randum'
+ _scons_clean_makeopts_perform_test '-kjrandum'
# needing stripping
- _scons-clean-makeopts-perform-test '--load-average=25 -kj16' '-kj16'
- _scons-clean-makeopts-perform-test '--load-average 25 -k -j17' '-k -j17'
- _scons-clean-makeopts-perform-test '-j2 HOME=/tmp' '-j2'
- _scons-clean-makeopts-perform-test '--jobs funnystuff -k' "--jobs=${jc} -k"
+ _scons_clean_makeopts_perform_test '--load-average=25 -kj16' '-kj16'
+ _scons_clean_makeopts_perform_test '--load-average 25 -k -j17' '-k -j17'
+ _scons_clean_makeopts_perform_test '-j2 HOME=/tmp' '-j2'
+ _scons_clean_makeopts_perform_test '--jobs funnystuff -k' "--jobs=${jc} -k"
}
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] New eclass: scons.eclass
2010-08-23 16:24 ` [gentoo-dev] " Michał Górny
@ 2010-08-23 16:39 ` Mike Frysinger
2010-08-23 17:16 ` Michał Górny
0 siblings, 1 reply; 34+ messages in thread
From: Mike Frysinger @ 2010-08-23 16:39 UTC (permalink / raw
To: gentoo-dev; +Cc: Michał Górny
[-- Attachment #1: Type: Text/Plain, Size: 786 bytes --]
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
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] New eclass: scons.eclass
2010-08-23 16:39 ` Mike Frysinger
@ 2010-08-23 17:16 ` Michał Górny
2010-08-23 20:22 ` Mike Frysinger
0 siblings, 1 reply; 34+ messages in thread
From: Michał Górny @ 2010-08-23 17:16 UTC (permalink / raw
To: gentoo-dev; +Cc: Mike Frysinger
[-- Attachment #1: Type: text/plain, Size: 1413 bytes --]
On Mon, 23 Aug 2010 12:39:50 -0400
Mike Frysinger <vapier@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:mgorny@jabber.ru>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] New eclass: scons.eclass
2010-08-23 17:16 ` Michał Górny
@ 2010-08-23 20:22 ` Mike Frysinger
2010-08-23 23:02 ` Michał Górny
0 siblings, 1 reply; 34+ messages in thread
From: Mike Frysinger @ 2010-08-23 20:22 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: Text/Plain, Size: 1054 bytes --]
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
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] New eclass: scons.eclass
2010-08-23 20:22 ` Mike Frysinger
@ 2010-08-23 23:02 ` Michał Górny
2010-08-23 23:27 ` Mike Frysinger
0 siblings, 1 reply; 34+ messages in thread
From: Michał Górny @ 2010-08-23 23:02 UTC (permalink / raw
To: gentoo-dev; +Cc: vapier
[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]
On Mon, 23 Aug 2010 16:22:35 -0400
Mike Frysinger <vapier@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:mgorny@jabber.ru>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] New eclass: scons.eclass
2010-08-23 23:02 ` Michał Górny
@ 2010-08-23 23:27 ` Mike Frysinger
2010-08-24 8:11 ` Michał Górny
0 siblings, 1 reply; 34+ messages in thread
From: Mike Frysinger @ 2010-08-23 23:27 UTC (permalink / raw
To: Michał Górny; +Cc: gentoo-dev
[-- Attachment #1: Type: Text/Plain, Size: 2101 bytes --]
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
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] New eclass: scons.eclass
2010-08-23 23:27 ` Mike Frysinger
@ 2010-08-24 8:11 ` Michał Górny
0 siblings, 0 replies; 34+ messages in thread
From: Michał Górny @ 2010-08-24 8:11 UTC (permalink / raw
To: Mike Frysinger; +Cc: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 998 bytes --]
On Mon, 23 Aug 2010 19:27:22 -0400
Mike Frysinger <vapier@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:mgorny@jabber.ru>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] New eclass: scons.eclass
2010-08-22 18:39 ` [gentoo-dev] " Michał Górny
` (3 preceding siblings ...)
2010-08-23 16:24 ` [gentoo-dev] " Michał Górny
@ 2010-08-24 18:40 ` Michał Górny
2010-08-24 21:30 ` Mike Frysinger
4 siblings, 1 reply; 34+ messages in thread
From: Michał Górny @ 2010-08-24 18:40 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1.1: Type: text/plain, Size: 397 bytes --]
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:mgorny@jabber.ru>
[-- Attachment #1.2: scons-utils.eclass --]
[-- Type: application/octet-stream, Size: 6268 bytes --]
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: scons.eclass
# @MAINTAINER:
# gentoo@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, escons() will use cleaned
# up MAKEOPTS instead.
# @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
# -- 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_, use cleaned MAKEOPTS
set -- scons ${SCONSOPTS-$(scons_clean_makeopts)} ${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
# 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
--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
done
set -- ${new_makeopts}
export _SCONS_CACHE_SCONSOPTS=${*}
debug-print "New SCONSOPTS: [${*}]"
echo ${*}
}
# @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#!}}
local vartrue=${3:-${USE_SCONS_TRUE}}
local varfalse=${4:-${USE_SCONS_FALSE}}
debug-print-function ${FUNCNAME} "${@}"
if [[ ${#} -eq 0 ]]; then
eerror "Usage: scons-use <use-flag> [var-name] [var-opt-true] [var-opt-false]"
die 'scons-use(): not enough arguments'
fi
if use "${flag}"; then
echo "${varname}=${vartrue}"
else
echo "${varname}=${varfalse}"
fi
}
# -- self-tests --
_scons_clean_makeopts_perform_test() {
local sconsopts=$(scons_clean_makeopts ${1})
if [[ ${sconsopts} != ${2-${1}} ]]; then
cat >&2 <<_EOF_
Self-test failed:
Input string: ${1}
Output string: ${sconsopts}
Expected: ${2-${1}}
_EOF_
fi
}
# Perform a self-test on scons-clean-makeopts.
_scons_clean_makeopts_tests() {
# jobcount expected for non-specified state
local jc=255
# sane MAKEOPTS
_scons_clean_makeopts_perform_test '--jobs=14 -k'
_scons_clean_makeopts_perform_test '--jobs=14 -k'
_scons_clean_makeopts_perform_test '--jobs 15 -k'
_scons_clean_makeopts_perform_test '--jobs=16 --keep-going'
_scons_clean_makeopts_perform_test '-j17 --keep-going'
_scons_clean_makeopts_perform_test '-j 18 --keep-going'
# needing cleaning
_scons_clean_makeopts_perform_test '--jobs -k' "--jobs=${jc} -k"
_scons_clean_makeopts_perform_test '--jobs --keep-going' "--jobs=${jc} --keep-going"
_scons_clean_makeopts_perform_test '-kj' "-kj ${jc}"
# broken by definition (but passed as it breaks make as well)
_scons_clean_makeopts_perform_test '-jk'
_scons_clean_makeopts_perform_test '--jobs=randum'
_scons_clean_makeopts_perform_test '-kjrandum'
# needing stripping
_scons_clean_makeopts_perform_test '--load-average=25 -kj16' '-kj16'
_scons_clean_makeopts_perform_test '--load-average 25 -k -j17' '-k -j17'
_scons_clean_makeopts_perform_test '-j2 HOME=/tmp' '-j2'
_scons_clean_makeopts_perform_test '--jobs funnystuff -k' "--jobs=${jc} -k"
}
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.3: scons-utils.eclass.diff --]
[-- Type: text/x-patch, Size: 2737 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related [flat|nested] 34+ messages in thread