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 l
* 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 exte
On Fri, 2023-04-21 at 09:16 +0200, Ralph Seichter wrote:
>
> I tried what you suggested. However, inheriting from ruby-ng.eclass
> introduces an odd problem: For some reason unknown to me, "${S}" no
> longer matches the default value of "${WORKDIR}/${P}", but only what I'd
> expect in "${WORKDIR}"
Hello Michael. Long time no read. ;-)
> I think the best way to support that in a package is to declare which
> ruby versions are supported with USE_RUBY and ruby-ng.eclass.
I tried what you suggested. However, inheriting from ruby-ng.eclass
introduces an odd problem: For some reason unknown to m
On 2023-04-19 01:08:23, Ralph Seichter wrote:
> I need to install Ruby bindings (something.so) during an ebuild,
> specifically into the /usr/lib64/ruby/vendor_ruby/3.0.0/x86_64-linux
> directory.
Hey Ralph. I'm not an expert on the ruby eclasses, but they work more
or less like the python ones, i
I need to install Ruby bindings (something.so) during an ebuild,
specifically into the /usr/lib64/ruby/vendor_ruby/3.0.0/x86_64-linux
directory. I scanned existing ebuilds for an example, but have not yet
found one. The developer manual [1] mentions newlib.so, but that
function appears to inject "/
6 matches
Mail list logo
