Dne 12.9.2012 09:54, Charles Oliver Nutter napsal(a):
On Wed, Sep 12, 2012 at 2:27 AM, Vít Ondruch <[email protected]> wrote:
I think, that for the platform specific bits, we should use subpackages and
somehow follow the RubyGems conventions, i.e. use -java for JRuby packages.
This is clear. Unfortunately, I am not sure how to distinguish between C
extensions for MRI and Rubinius for example (neither I really explored, what
are the possibilities, but I am afraid, that it will not be that easy :/).
My understanding is that the *sources* of the extensions should be the
same for both MRI and Rubinius, but the *binaries* are definitely
different. For example, a number of things MRI defines as macros
directly into MRI-specific struct layout are actually functions in
Rubinius...so an extension build for one definitely will not work on
the other.
Exactly.
What I am afraid that RubyGems can't distinguish between gems for
Rubinius and MRI as it can't differentiate between binary gems built for
MRI 1.8 or MRI 1.9. For example, for therubyracer gem [1], you can get
prebuilt gems, but I doubt they can work for Ruby 1.8 and 1.9 as well.
There are "fat binary" gems for Windows (e.g. nokogiri), but that is
more or less workaround, which doesn't scale. RubyGems should support
more than platform to choose the correct gem version.
Vit
[1] https://rubygems.org/gems/therubyracer
- Charlie
_______________________________________________
ruby-sig mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
_______________________________________________
ruby-sig mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
