On Thu, Apr 16, 2009 at 8:53 PM, Daniel Berger <djber...@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 AREA 17 - 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 _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
