* Michael Orlitzky:
> The eclass sets S=$WORKDIR at first because it creates a separate
> source tree for each version of ruby that will be built for. [...]
Hm. While that sounds useful for "full Ruby" ebuilds, I don't see how to
circumvent the impact for the particular ebuild I am trying to extend,
other than overriding S in src_compile() etc.
The build needs to create a C shared library, Python bindings, and now
an additional shared library containing the Ruby bindings. Might this be
a case where a new, separate ebuild for the Ruby bindings would be a
better option than expanding the existing build?
> That uses the currently-eselected version of ruby to determine the
> path though.
I thought of that and tried to use ${RUBY} instead, but the variable was
empty. Hence I use the literal 'ruby' as a workaround, until a better
method comes to mind.
-Ralph
