Hello Tony. On Tue, Aug 31, 2010 at 10:48 PM, Tony Arcieri <tony.arci...@medioh.com> wrote: > Context for the problem is here: > > But IronRuby isn't the only concern. What about MagLev? Or BlueRuby? There > are a lot of alternative Ruby implementations out there which don't provide > the MRI C extension API. Using a gem like "json" on these platforms is > broken-by-default, since the "default" platform is called "ruby", and the > "ruby" platform seems to assume out-of-the-gate that you can install C > extensions, when in fact the opposite is true. Support for MRI C extensions > is almost a rarity when it comes to the totality of Ruby implementations > available, with the only implementations supporting them are MRI, YARV, > Rubinius, and JRuby to a limited extent. > > For these platforms, there's the "json_pure" gem. This gem exposes (in > theory!) the same API as the json gem, but is implemented in pure Ruby. > However, when trying to specify dependencies, which gem does one pick? > json_pure is the least common denominator, but as has been seen in practice > in Resque, compatibility issues can arise: > > http://librelist.com/browser//resque/2010/8/13/issue-with-json-pure...<http://librelist.com/browser//resque/2010/8/13/issue-with-json-pure-stack-level-too-deep-resque-+-resque-status/> > > My immediate proposed solution for the resque/json scenario is: > > MRI/YARV/Rubinius: use the C extension > JRuby: use the Java version > IronRuby: package json_pure as "json" > Other platforms: you're screwed >
There are a few ways to solve this: json gem provides the pure-ruby version of JSON specification json_ext provides the C, JRuby or whatever-under-the-sun required for each platform (-java, windows binaries, etc). json gem tries to use json_ext and on failure falls back to pure-ruby version. > 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. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
