Hello devs,

I've just committed a new eclass to gx86 -- it's called scons-utils
and it's supposed to help creating clean ebuilds for packages using
the SCons buildsystem.

Right now, the eclass addresses the two following important issues:

${MAKEOPTS} cleaning
--------------------

Currently the ebuilds either ignore MAKEOPTS completely, pass it
unmodified or clean it up a little using a copy-paste sed expression.

The scons-utils eclass introduces scons_clean_makeopts() function which
is able to nicely adjust MAKEOPTS to fit SCons. But in fact, you
probably won't ever need to call it -- escons() does it for you.

use_scons()
-----------

Right now, ebuilds use complex variable mangling in order to prepare
SCons variable assignments based on USEflags. Consider the following
code snippet (from media-sound/mixxx):

use hifieq && mysconsargs+=" hifieq=1" || mysconsargs+=" hifieq=0"

With scons-utils you can move this into actual `mysconsargs`
declaration, putting it like that:

$(use_scons hifieq)


Trivial use example
-------------------

Well, enough talking. Now a simple example on how to use it:


inherit scons-utils

src_compile() {
escons
$(use_scons nls gettext)
$(use_scons ssl)
}


`escons` here is similar to emake. It simply calls scons, passing
appropriate flags to it. If SCONSOPTS is set (optional, supposed to be
set in make.conf, never mangle it in ebuilds!), it will be used;
otherwise, scons-utils will use cleaned up version of MAKEOPTS.

`use_scons <flag>` outputs either `<flag>=0` or `<flag>=1` depending on
whether the <flag> flag is set.

`use_scons !<flag>` would output: `no<flag>=1` or `no<flag>=0`.

`use_scons <flag> <var>` outputs: `<var>=0` or `<var>=1`, checking
<flag> flag.

For a few more tricks, please take a look at the eclass docs.

Thank you for your attention. If you have any questions, I'll be happy
to answer them.

--
Best regards,
Michał Górny

On Thu, 7 Oct 2010 21:35:13 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> I've just committed a new eclass to gx86

= Adding and Updating Eclasses =

Before committing a new eclass to the tree, it should be emailed to
the gentoo-dev mailing list with a justification and a proposed
implementation. Do not skip this step — sometimes a better
implementation or an alternative which does not require a new eclass
will be suggested. [1]


You never proposed this to the gentoo-dev mailing list?


jer



[1] http://devmanual.gentoo.org/eclass-writing/index.html

On 08-10-2010 18:40, Jeroen Roovers wrote:

On Thu, 7 Oct 2010 21:35:13 +0200
Michał Górny<mgorny@gentoo.org> wrote:


I've just committed a new eclass to gx86


= Adding and Updating Eclasses =

Before committing a new eclass to the tree, it should be emailed to
the gentoo-dev mailing list with a justification and a proposed
implementation. Do not skip this step — sometimes a better
implementation or an alternative which does not require a new eclass
will be suggested. [1]


You never proposed this to the gentoo-dev mailing list?


jer



It was discussed in the thread with subject:
New eclass: scons.eclass

Cheers,

--
Gökdeniz Karadağ

On Fri, 08 Oct 2010 18:43:50 +0300
Gökdeniz Karadağ <gokdenizk@gmail.com> wrote:

> It was discussed in the thread with subject:
> New eclass: scons.eclass

Thanks for the update. This leads me to two suggestions for future
eclass addition announcements:

1) Refer to the original gentoo-dev thread(s) (as recorded on
archives.g.o).
2) If in that thread discussion leads to a change in the name for the
proposed eclass, rename the thread accordingly.


jer