Prepping your Gemfile for Rubinius
Rubinius 2.0 is on it’s way and it’s shaping up to be a serious contender. Adding support for Rubinius to your gem should be pretty painless.
Here at [i] it’s common for us to depend on support utilities like ruby-debug or perftools. Fortunately Rubinius comes with a very solid debugger and profiler. The best solution I’ve found is to use Bundler’s :platform rules to limit those libraries to Matz’s ruby.
In your Gemfile:
gem 'ruby-debug', :platform => :mri_18
gem 'ruby-debug19', :platform => :mri_19, :require => 'ruby-debug'
gem 'perftools.rb', :platform => :mri, :require => 'perftools'
And then inside your spec helper or test helper use bundler to only require the dependencies you need for that platform:
require 'bundler/setup'
Bundler.require(:default, :development)
And that’s it.
About Chris Gaffney
This Michigan native brings a plethora of experience in event-driven programming and hardware integration systems. He’s also responsible for driving forward our product, Dead Man’s Snitch.
Comments
If you’re using Bundler’s ‘gemspec’ method, this won’t work. You will need to use something like this directly in your .gemspec file:
if !defined?(RUBY_ENGINE) || RUBY_ENGINE != ‘rbx’ s.add_development_dependency ‘rcov’, ‘~> 0.9’ s.add_development_dependency ‘metric_fu’, ‘~> 2.1’ end
Ah the wicked webs we weave. See using gemspec, not a great idea really. And using environment conditions, even worse. Essentially you’ve tied your gem build to your environment, so the .gem file will com out different depending on your current rvm selection. Remember the gemspec if not copied to .gem it is processed and saved a static YAML.
trans: it is development and test dependencies that we really use this for. We let the gemspec define the gem’s requirements, and the Gemfile can handle dev & test.
Hi everyone, I am sure you will be enjoying here by watching these kinds of comic movies.