On Fri, 2023-04-21 at 22:15 +0200, Ralph Seichter wrote:
>
> 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?
> >
Ultimately what you want to do is build all of that other stuff once,
and then build ruby binding for each version of ruby. You can probably
make that happen by mucking around with the each_ruby_foo and
all_ruby_foo phases, but I think a separate ebuild would work too.
Assuming that the bindings link to the library, in both cases you face
the same problem: to convince the build system to link against a
different copy of the C library. With a single ebuild, you want the
ruby-specific builds to link against the one shared library you just
built; with a separate ebuild you'd want them all to link against the
system copy that was installed by the main ebuild.
> 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.
One final option would be to figure out how the eclass is finding the
supported ruby versions, and copy it. Then you could loop through them
and use your hack with each one.
