title: Native extensions fallback to pure Ruby if not supported on gem install
body: <p>I am developing a gem, which is currently pure Ruby, but I have also been developing a faster C variant for one of the features. The feature is usable, but sometimes slow, in pure Ruby. The slowness would only impact some of the potential users (depends which features they need, and how they use them), so it makes sense to have the gem available with graceful fallback to Ruby-only functions if it cannot compile on a target system.</p>
  
  <p>I would like to maintain the Ruby and C variants of the feature in a single gem, and provide the best (i.e. fastest) experience from the gem on installation. That would allow me to support the widest set of potential users from a single project of mine. It would also allow other people's dependent gems and projects to use the best available dependency on a target system, as opposed to a lowest-common-denominator version for compatibility.</p>
  
  <p>I would expect the <code>require</code> to fallback at runtime to appear in the main <code>lib/foo.rb</code> file simply like this:</p>
  
  <pre><code>begin
    require 'foo/foo_extended'
  rescue LoadError
    require 'foo/ext_bits_as_pure_ruby'
  end
  </code></pre>
  
  <p>However, I don't know how to get the gem installation to check (or try and fail) for native extension support so that the gem installs correctly whether or not it can build 'foo_extended'. When I researched how to do this, I mainly found discussions from a few years back e.g. <a href="http://permalink.gmane.org/gmane.comp.lang.ruby.gems.devel/1479" rel="nofollow noreferrer">http://permalink.gmane.org/gmane.comp.lang.ruby.gems.devel/1479</a> and <a href="http://rubyforge.org/pipermail/rubygems-developers/2007-November/003220.html" rel="nofollow noreferrer">http://rubyforge.org/pipermail/rubygems-developers/2007-November/003220.html</a> that imply Ruby gems do not really support this feature. Nothing recent though, so I am hoping someone on SO has some more up-to-date knowledge?</p>
  
  <p>My ideal solution would be a way to detect, prior to attempting a build of the extension, that the target Ruby did not support (or perhaps simply not want, at the project level) C native extensions. But also, a try/catch mechanism would be OK if not too dirty.</p>
  
  <p>Is this possible, if so how? Or is the advice to have two gem variants published (e.g. <code>foo</code> and <code>foo_ruby</code>), that I am finding when I search, still current best practice?</p>