| Summary: | Provide eclass support for libraries with ruby bindings | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Hans de Graaff <graaff> |
| Component: | Eclasses | Assignee: | 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 | ||
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. 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. 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. 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_*"). |
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.