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>

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>

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

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>

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

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

On Tue, 24 Aug 2010 17:30:32 -0400
Mike Frysinger <vapier@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:mgorny@jabber.ru>

Hello,

I'm attaching the latest scons-utils.eclass once again, and announcing
the last call for criticism. If there are no further complaints, I will
proceed with committing.

--
Best regards,
Michał Górny

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

On Wed, 6 Oct 2010 12:52:33 -0500
Donnie Berkholz <dberkholz@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