How to create a gem which conditionally compiles/installs a C extension?

I have a gem that needs to compile and install a C extension on MRI
1.9.2. But on MRI 1.9.3 it doesn’t. What’s the best way to accomplish
this?

Here are some possibilities and the ramifications of them.

  • Create the gem in such a way to distinguish MRI 1.9.3 versus MRI
    1.9.2. I think this would be the cleanest, but I don’t think this is
    possible. Were this possible, in the gemspec one could
    put something add like:

    Gem::Specification.new do |spec|
    spec.extensions = [‘ext/extconf.rb’] if ‘1.9.2’ == RUBY_VERSION

  • Create a bogus extension for 1.9.3. This forces users to have a C
    compiler installed when it’s really not needed. This also has the
    possibly weird effect that if the gem was originally built for 1.9.3 and
    one goes back to 1.9.2 and that extension is around and gems are shared
    across 1.9.3 and 1.9.2 then this breaks. (The more expected direction of
    building on 1.9.2 and upgrading to 1.9.3 would work however because on
    1.9.3 the code doesn’t try to load the extension). Perhaps this is too
    much of an edge case to be concerned about.

  • Figure out some way in the gem to dynamically disable compiling the
    extension on MRI 1.9.3. For example in ext/extconf.rb:

    if ‘1.9.2’ == RUBY_VERSION
    create_makefile(…)
    else
    ???
    end

Thoughts and comments?

  • Figure out some way in the gem to dynamically disable compiling the
    extension on MRI 1.9.3. For example in ext/extconf.rb:

    if ‘1.9.2’ == RUBY_VERSION
    create_makefile(…)
    else
    ???
    end

Gem::Ext::ExtConfBuilder makes this difficult by (incorrectly)
assuming it should always run make after extconf.rb; you must create a
Makefile (even if it’s just a no-op stub) and have an activated make on
your system.

I recently had a similar idea (comined pure-ruby and native gem with
build decision made at install time by extconf.rb) and briefly toyed
with wrapping the extconf.rb with a Rakefile. The quick hack didn’t
work, and I haven’t had time to swing back and dance with the little
monster.

https://github.com/jonforums/ffi-bogus

Perhaps it just needs another set of eyes and a bit more time. That
said, a Rakefile + extconf.rb solution is a kludge. The right solution
is to find a clever way to make RubyGems more nimble and not break
existing extconf.rb builds.

Jon

Jon F. wrote in post #1086252:

  • Figure out some way in the gem to dynamically disable compiling the
    extension on MRI 1.9.3. For example in ext/extconf.rb:

    if ‘1.9.2’ == RUBY_VERSION
    create_makefile(…)
    else
    ???
    end

Gem::Ext::ExtConfBuilder makes this difficult by (incorrectly)
assuming it should always run make after extconf.rb; you must create a
Makefile (even if it’s just a no-op stub) and have an activated make on
your system.

I recently had a similar idea (comined pure-ruby and native gem with
build decision made at install time by extconf.rb) and briefly toyed
with wrapping the extconf.rb with a Rakefile. The quick hack didn’t
work, and I haven’t had time to swing back and dance with the little
monster.

https://github.com/jonforums/ffi-bogus

Perhaps it just needs another set of eyes and a bit more time. That
said, a Rakefile + extconf.rb solution is a kludge. The right solution
is to find a clever way to make RubyGems more nimble and not break
existing extconf.rb builds.

Agreed.

I couldn’t see how to make it work either. So until something better
comes along I’ve gone with the bogus C extension approach when it is not
needed.

See https://github.com/rocky/rb-threadframe/tree/master/ext

Jon

Rocky B. wrote in post #1086286:

Jon F. wrote in post #1086252:

  • Figure out some way in the gem to dynamically disable compiling the
    extension on MRI 1.9.3. For example in ext/extconf.rb:

    if ‘1.9.2’ == RUBY_VERSION
    create_makefile(…)
    else
    ???
    end

Gem::Ext::ExtConfBuilder makes this difficult by (incorrectly)
assuming it should always run make after extconf.rb; you must create a
Makefile (even if it’s just a no-op stub) and have an activated make on
your system.

I recently had a similar idea (comined pure-ruby and native gem with
build decision made at install time by extconf.rb) and briefly toyed
with wrapping the extconf.rb with a Rakefile. The quick hack didn’t
work, and I haven’t had time to swing back and dance with the little
monster.

https://github.com/jonforums/ffi-bogus

Perhaps it just needs another set of eyes and a bit more time. That
said, a Rakefile + extconf.rb solution is a kludge. The right solution
is to find a clever way to make RubyGems more nimble and not break
existing extconf.rb builds.

Agreed.

I couldn’t see how to make it work either. So until something better
comes along I’ve gone with the bogus C extension approach when it is not
needed.

See https://github.com/rocky/rb-threadframe/tree/master/ext

Jon

Sigh.

The gems have been released and my patience for gem hacking has worn
very thin.

Tell you what… fork the code, patch it and submit a merge request on
github. Then I’ll try it out in the various circumstances.

One potential problem I see (as mentioned previously) is that if one
goes from MRI 1.9.3 to 1.9.2 the extension won’t be there and you’ll get
an error. Right now what happens is that the C extension checks the Ruby
version and suggests reinstalling the gem. This is a slightly better
failure message.

But again, what’s really needed here is more and better gem intelligence
with regard to the version of Ruby that one is running.

I recently had a similar idea (comined pure-ruby and native gem with
build decision made at install time by extconf.rb) and briefly toyed
with wrapping the extconf.rb with a Rakefile. The quick hack didn’t
work, and I haven’t had time to swing back and dance with the little
monster.

https://github.com/jonforums/ffi-bogus

Perhaps it just needs another set of eyes and a bit more time. That
said, a Rakefile + extconf.rb solution is a kludge. The right solution
is to find a clever way to make RubyGems more nimble and not break
existing extconf.rb builds.

Agreed.

I couldn’t see how to make it work either. So until something better
comes along I’ve gone with the bogus C extension approach when it is not
needed.

See https://github.com/rocky/rb-threadframe/tree/master/ext

When you get a moment would you try replacing

https://github.com/rubygems/rubygems/blob/master/lib/rubygems/ext/builder.rb#L15-L17

with this little hack

return unless File.exist? ‘Makefile’

and try your idea of not creating a Makefile from extconf.rb upon
certain conditions.

It assumes (a) all sucessful exits from extconf.rb (with or without
generating a Makefile) is what the author intended, and (b) all
extconf.rb failures will be handled as-is by RG.

When I get time I’ll test on both my Win7 and Arch systems. If it turns
out to be this easy and solid, well…

Jon

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs