From: Jeremy McAnally Date: 2008-07-30T15:11:18+09:00 Subject: [ruby-core:18023] Re: RUBY_ENGINE? Exactly. This constant would've been infinitely helpful to a project I was working on where we're deploying to JRuby but developing on MRI. It's difficult to conditionally require gems that require special versions such as Hpricot without knowing which engine we're running on. --Jeremy On Sun, Jul 27, 2008 at 10:28 PM, Charles Oliver Nutter wrote: > Laurent Sansonetti wrote: >> >> On Sun, Jul 27, 2008 at 2:35 PM, Hongli Lai wrote: >>> >>> Yukihiro Matsumoto wrote: >>>> >>>> Don't be so quick. You guys haven't made it clear that >>>> >>>> * 1.8 and 1.9 can share same RUBY_ENGINE value (since both of them >>>> are "my" ruby), or not (since they are different) >>> >>> They are both MRI. But it's easy to distinguish between them by checking >>> RUBY_VERSION. >>> >>>> * plain 1.8 and RubyEnterpriseEdition (or other forks) can share >>>> same RUBY_ENGINE (since they are almost identical), or not (since >>>> they are different after all). >>> >>> Ruby Enterprise Edition is meant to be fully compatible with MRI. It's >>> basically just MRI + GC patches + a different memory allocator. There are >>> no >>> language-level changes or binary compatibility issues, so as far as the >>> script is concerned it's just MRI. >>> >> >> Mmh, Ruby Enterprise Edition is compatible with MRI, but the engine >> (which this constant is supposed to represent?) under the covers is >> not the exact same one. >> >> # MacRuby is supposed to be somewhat compatible with MRI 1.9 too. But >> it has a different memory allocator, GC, object model, dispatcher, ... >> in other words, a completely different engine. > > Rubinius is intended to be compatible with MRI 1.8. JRuby is intended to be > compatible with MRI 1.8 and 1.9. IronRuby is intended to be compatible with > MRI 1.8. I don't think that reduces the need for a specific constant > describing which implementation/codebase you're running on. > > All Ruby implementations are intended to be compatible...otherwise they > wouldn't be Ruby. MacRuby would probably want to specify RUBY_ENGINE as > "macruby" since as you state it is a different engine underneath that will > have different quirks. Also in MacRuby's case, there's a pretty seamless > two-way integration with ObjC, so people would use RUBY_ENGINE == "macruby" > to know if they should load their ObjC-based libraries. > > So like JRuby with Java, Rubinius with various extensions to core classes > and a differen execution/IO/threading model, IronRuby with .NET, MagLev with > potentially SmallTalk-based libraries...it's a perfect way to identify "hey, > I'm on implementation X and can expect features/bugs/quirks of that > implementation to be present." > > - Charlie > > -- http://jeremymcanally.com/ http://entp.com/ http://omgbloglol.com My books: http://manning.com/mcanally/ http://humblelittlerubybook.com/ (FREE!)