Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Add MagLev to platform map #2149

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
3 participants
Contributor

jc00ke commented Nov 6, 2012

Unsure if this is needed, but surprised it wasn't included. Please close if it's unnecessary. Thanks!

Owner

indirect commented Nov 11, 2012

@jc00ke is MagLev a separate platform? as in, does it provide a binary interface for gems that differs from the interface provided by MRI or Rubinius or JRuby? Gemfile platforms basically exist because some gems explode if you try to install them against the wrong ruby, and we're trying to prevent that. If MagLev has gems that only work when installed with MagLev, we probably need a platform for it. Is that the case?

Contributor

jc00ke commented Nov 11, 2012

I don't know enough about how MagLev handles gems, and if it provides a binary interface. @Monty, @pbm & @timfel could offer more here.

The MagLev team has patched certain gems, along with Bundler. It would be nice if we could figure out a way to avoid these forked/patched gems, but I think that is another thing entirely.

Contributor

timfel commented Nov 11, 2012

MagLev has a C extension API that is close to MRIs, but not quite the same in many ways due to differences in the VM. Enough so that we publish our own versions of many gems (nokogiri, json, bcrypt, eventmachine). We patch our shipped Rubygems and Bundler to look for gems of the requested name that have a "-maglev-" postfix, and publish our modified gems with the name changed in this manner. This is a bit magical and the patches have to change every other version of rubygems and bundler. Our Gems usually use C Api not available on MRI to work around issues with MagLev, so you could say that MagLev should be a separate platform.

If MagLev were added to the platform map, we could disable our patch for bundler, which would make it easier for us to ship updated versions (also people updating bundler on their own wouldn't suddenly not get custom MagLev gems when before they did)

Owner

indirect commented Nov 12, 2012

@timfel it sounds like you guys should be building gems that declare their platform to be MagLev, like how JRuby does. There's a (small) reference for the Gem::Specification platform attribute here. Is that not an option for some reason?

Gems like Nokogiri, which publish for each platform, work without any platform calls in a Gemfile. The Bundler platform method is really just a hack on top of the Gemfile to try to make it easier for end users to include or exclude gems that are specific to certain platforms.

Based on what you said above, I can see how there might be an argument to add a MagLev platform to Bundler, but the specific reason you describe should already be handled by Rubygems itself, without any changes to Bundler at all.

Contributor

timfel commented Nov 15, 2012

as i understand it, a rubygems platform will prevent maglev users from easily installing those c extension gems that just work, and force us to "sanction" every c extension by pushing a variant that declares it as a maglev extension gem. the ultimate goal is that (as on rubinius) most if not all c extensions a user might install just work as they would on mri. adding a maglev bundler platform will allow us to work around any issues, until they can be addressed with patches to the gems or maglev's c extension api.

Owner

indirect commented Nov 15, 2012

As far as I know, any gem that does not have a version that declares a maglev platform will be installed normally. Platforms are only for gems that have platform-specific differences.

On Nov 15, 2012, at 10:05 AM, Tim Felgentreff notifications@github.com wrote:

as i understand it, a rubygems platform will prevent maglev users from easily installing those c extension gems that just work, and force us to "sanction" every c extension by pushing a variant that declares it as a maglev extension gem. the ultimate goal is that (as on rubinius) most if not all c extensions a user might install just work as they would on mri. adding a maglev bundler platform will allow us to work around any issues, until they can be addressed with patches to the gems or maglev's c extension api.


Reply to this email directly or view it on GitHub.

@rohit rohit referenced this pull request Nov 22, 2012

Closed

Adding MagLev to man page #2148

Owner

indirect commented Feb 15, 2013

Closing for now, since MagLev seems to be okay without it being implemented so far.

@indirect indirect closed this Feb 15, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment