[Rubygems-developers] Is a "pure" platform needed?

James Tucker jftucker at gmail.com
Fri Sep 10 17:51:34 EDT 2010

On 10 Sep 2010, at 18:22, Luis Lavena wrote:
> json gem tries to use json_ext and on failure falls back to pure-ruby version.

We need to add a feature to really support this. The problem is, gems that fail to build although left on the filesystem for debugging purposes and to allow access to the build logs, they are not added to the installed index, and as such are not loadable except under old gem_prelude bugs.

Maybe a gemspec option ext_optional or pure_option, or some better name?

>> The question is, how can we solve this problem for not only IronRuby, but
>> all other Ruby platforms without C extension support? (e.g. BlueRuby,
>> MagLev). I would propose Ruby implementers add some check to their
>> implementation RubyGems can use to determine if MRI-style C extensions are
>> supported, and if they are not supported for this platform, the "pure"
>> implementation be used in lieu of the "ruby" implementation.
> There is another approach which is a dummy_makefile by mkmf, been
> discussed here:
> http://rubyforge.org/tracker/index.php?func=detail&aid=28366&group_id=126&atid=578
> But it assumes that:
> 1) mkmf provided by your Ruby implementation actually works (mkmf in
> JRuby says that is not supported and fails), at least providing the
> minimum checking to create this dummy makefile.
> 2) Your environment provides a sane build environment capable of invoking "make"
> This one highly unlikely is going to work for IronRuby or others that
> do not support C extensions (like MagLev, which endorses FFI) or not
> provide a sane build environment.
> If we can make RubyGems more smart in relation to extensions and when
> it fails to compile them somehow, then the issue with pure ruby
> extensions and C extensions is gone.

I have proposed a number of times moving toward a single script invocation (maybe with some build helpers) rather than having specifically matched build types.

So, that would be moving towards having spec.extensions simply call:

	spec.extensions.each { |e| system Gem.ruby, e }

We could have very simple helpers for migration, like so:

	require "rubygems/extconf_make" # calls at_exit { system ENV['make'] || 'make' }
	require "rubygems/mkrf_make"    # calls at_exit { system "rake" } # n.b. the correct path and bin name ofc.

You get the idea. We would migrate the old methods out in the long term, and then deprecate these. This way RubyGems can drop all specific build methods, and simply execute a single ruby script for each extension in the gem. If further utilities are required, they can be provided by the Gem api, or separate gems which may be dependencies (for example an extended mkmf, some helpers from rake-compiler, or the like).

More information about the Rubygems-developers mailing list