[Rubygems-developers] The case of binary gems and Ruby versions.

Luis Lavena luislavena at gmail.com
Thu Apr 16 20:33:21 EDT 2009

On Thu, Apr 16, 2009 at 8:53 PM, Daniel Berger <djberg96 at gmail.com> wrote:
> Eric Hodel wrote:
>> On Apr 16, 2009, at 03:11, Luis Lavena wrote:
>>> Been investing a lot of time in Ruby 1.9 as I move forward for updated
>>> RubyInstaller (One-Click) for both 1.8.6 and 1.9.x branches.
>>> Because of that, I've started to realize, even more and more, that
>>> distributing binary gems between versions is set to failure.
>>> Let me explain my logic with a simple example.
>>> My gem contains a extension, which I compile, cross-compile and
>>> package for 'i386-mswin32' (x86-mswin32) using my stock Ruby 1.8.6
>>> installation. I can also compile for the new RubyInstaller platform
>>> (mingw32) using the same approach.
>>> At the time I upload that to rubyforge, I upload the following files:
>>> my-gem-1.0.gem
>>> my-gem-1.0-x86-mswin32-60.gem
>>> my-gem-1.0-x86-mingw32.gem
>>> At this point, everything is good.
>>> Since the last 2 gems listed there are binary gems, those will be
>>> linking with msvcrt-ruby18.dll, which is the runtime library for Ruby
>>> on Windows (both MinGW and VC6). No problem so far.
>>> You wonder, where is the problem then?
>>> These gem where built for 1.8, so installing those in 1.9 will not
>>> fail unless I specify require_ruby_version (which is something
>>> rake-compiler now does).
>>> Now, the real problem becomes when I want to provide binaries for BOTH
>>> ruby version, since RubyGems, besides the required_ruby_version don't
>>> provide a mechanism to distinguish 1.8 from 1.9 gems, I end with the
>>> exact same gem names, with the exact same versions and platforms, thus
>>> overwriting previous versions.
>>> Someone suggested me that release 1.0.0 for Ruby 1.8 and 1.1.0 for
>>> Ruby 1.9, but that is misleading.
>>> I think we reached the point where RubyGems roadmap needs to start
>>> considering these cases to provide a more mature solution for us.
>> I see two solutions:
>> Package two separate gems with an indicator in the name for 1.8 vs 1.9
>> Package a gem with both libraries inside, and add something to
>> require_paths for 1.8 vs 1.9
> Could this be automated somehow? Can we dynamically set the linkage within a
> gem on Windows based on the version of Ruby that's running it?

The extension link to so many different functions inside libruby that
perform the linkeage is kind of impossible.

An alternative will be build two versions of the same extension
(my_ext18 and my_ext19) and load it accordingly, but that's another
compilation complication that developers will need to work out.

Luis Lavena
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

More information about the Rubygems-developers mailing list