Bug 352765 – ruby-fakegem should better-facilitate the compilation and installation of shared libraries

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Dean Matzkov 2011-01-26 00:08:44 UTC]

Some gems come bundled with an `ext' directory that contains C source code, which needs to be compiled, with the resulting *.so file having to be moved to the`lib' directory.

Currently, there is no way to automate/wrap this common task. For every gem that has a binary component, the same boilerplate code needs to be in the ebuild:

${RUBY} extconf.rb # this spits out a Makefile
emake CLFAGS="${CFLAGS} -fPIC" archflags="${LDFLAGS}"
cp ext/somelib.so lib


However, if automating this is impractical, I think at least creating a wrapper such as `ruby_fakegem_dolib.so' to install into the gem's `lib' dir (with the `.so' added to make it explicit that it's used for installing shared binaries) would be useful.

Without something like that, inelegant methods like the following have to be used:

each_fakegem_install() {
    local dest="${ED}/$(ruby_fakegem_gemsdir)/gems/${P}"
    cp ext/somelib.so "${dest}"/lib

    # or, alternatively to the above:
    ruby_fakegem_newins ext/somelib.so lib/somelib.so
}

or we can even be lazy and install the *.so file to `lib' in the src_compile phase, so that ruby_fakegem_install() can take care of it for us later:

each_fakegem_compile() {
    # compilation stuff here
    cp ext/somelib.so lib
}


A function for referring to the gem's installation directory for the src_install phase would also be nice.

Thanks.

[Comment 1 Hans de Graaff 2021-02-08 07:02:30 UTC]

ruby-fakegem.eclass now has support for compiled extensions with RUBY_FAKEGEM_EXTENSIONS and RUBY_FAKEGEM_EXTENSION_LIBDIR.