From: Ken Bloom Date: 2008-11-04T10:08:35+09:00 Subject: Re: Different flavors of a gem for different versions of Ruby On Sun, 02 Nov 2008 07:37:17 -0500, David Palm wrote: > Take a look at how the mongrel gem is doing it. It uses a bunch of > conditionals to distinguish actions to perform for jruby and mri. adding > in Ruby 1.9 support is (fairly) easy. > > I forked mongrel the other day so I could take out the fasterthread > dependency (not needed for 1.8.6+); might be useful: > http://github.com/dvdplm/mongrel/tree/master > > (and I'm sure it can be done more elegantly!) > > On Sun, 2 Nov 2008 14:38:53 +0900, Ken Bloom wrote: >> I'm updating my SqlStatement gem http://sqlstatement.rubyforge.org/ to >> be compatible with Ruby 1.9, and owing to totally different ways of >> doing s- expressions in Ruby 1.8 (which required RubyNode) and 1.9 >> (which can trap the not and != operators as methods, so I can use the >> interpreter itself to generate everything I need in an s-expression), >> the Ruby 1.9 version no longer requires a dependency on RubyNode. In >> fact, RubyNode doesn't exist for 1.9 AFAICT. >> >> Is there a way to do one of the following in RubyGems? >> * create a Ruby 1.8 flavor of the gem and another Ruby 1.9 flavor. >> Preferably, I'd like the gems to have the same name and live side-by >> side on RubyForge. >> or >> * Have both versions of the dependencies exist in a single gem, >> but only enforce the RubyNode dependency when the gem is installed >> on Ruby 1.8. AFAICT from the metadata of the generated gems, this doesn't do what I want. It generates different gems on different versions of ruby, but there's no indication that these gems are different in the end. By the way, I think you have a bug: if you generate the gem on Ruby 1.8.6, it will be installable on Ruby 1.8.4 but won't include the fastthread dependency. --Ken -- Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory. Department of Computer Science. Illinois Institute of Technology. http://www.iit.edu/~kbloom1/