Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 444828

Summary: Provide eclass support for libraries with ruby bindings
Product: Gentoo Linux Reporter: Hans de Graaff <graaff>
Component: EclassesAssignee: Gentoo Ruby Team <ruby>
Status: CONFIRMED ---    
Severity: normal CC: gnome, sam, tetromino, zerochaos
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 475624, 513888    

Description Hans de Graaff gentoo-dev Security 2012-11-26 18:39:58 UTC
Packages (mostly libraries) that also provide ruby bindings can't use the current ruby eclasses since these take over the phase functions. This combines badly with normal ebuilds, and even more so when these ebuilds also try to provide bindings for other languages which might need similar mechanisms.

Examples of such a package is net-analyzer/rrdtool

Rick suggested to just use something similar to what python does, e.g.

  if [[ -n "${PYTHON_EXPORT_PHASE_FUNCTIONS}" ]]; then
    EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test src_install
  fi

This would allow the ebuild to call the phase loops directly and thus install the ruby specific parts in its own way.
Comment 1 Diego Elio Pettenò (RETIRED) gentoo-dev 2012-11-26 18:42:37 UTC
Hrm, I'm not sure how much of a difference this makes — I mean it still boils down to call ruby-ng_src_(prepare/configure/compile/test/install) so why not just override the defaults in the ebuild and then call them?

By not using EXPORT_FUNCTIONS you can enter a bad situation where ruby-ng's src_prepare is not called but src_compile is.

I'm afraid my best suggestion would still be to split out the bindings on their own ebuilds.
Comment 2 Hans de Graaff gentoo-dev Security 2012-11-26 20:36:39 UTC
We could also simply document that all phase function will need to be made explicit. This would have the same effect.

One problem remains: in EAPI=4,5 we tinker with S in global scope which probably breaks the ebuild's assumptions about where to find the source. (Needs to be tested).

It would also be nice to provide an easy method to create the RUBY_TARGETS based source directories given a specific source directory. This would make it a lot easier to set things up properly for ruby.

Both items are linked since they both play with the expected locations of the ruby source code.
Comment 3 Diego Elio Pettenò (RETIRED) gentoo-dev 2012-11-26 23:34:06 UTC
I would also argue at that point that we need a ruby-ng-utils.eclass and import that in ruby-ng

So then you have the following cascade:

 - ruby-ng-utils: for C libraries with Ruby bindings;
 - ruby-ng: for Ruby libraries and C extensions;
 - ruby-fakegem: for Rubygems.

Each one on top of the one before.
Comment 4 Alexandre Rostovtsev (RETIRED) gentoo-dev 2013-10-05 11:37:10 UTC
There is also the case of non-ruby packages that use ruby scripts or rake in their build systems, but don't install anything ruby-related. One example would be net-libs/webkit-gtk.

So for these, an equivalent of python-any-r1.eclass would be helpful, with the following functionality:

* set a range of ruby implementations (e.g. via USE_RUBY)
* do NOT require the ebuild to have ruby_targets_* in IUSE (we don't want "emerge --update --newuse --deep @world" to rebuild webkit-gtk just because a new version of ruby was released!)
* a function to generate an || ( ) dependency string from USE_RUBY for use in DEPEND
* a function to export the "best" ruby interpreter as RUBY, based on USE_RUBY and the actual ruby packages installed on the system (not using "use ruby_targets_*").