It does seem like there isn’t a way to distinguish between IronRuby and MRI.

C:\> ir.exe
>>> require "rubygems"
=> true
>>> Gem::Platform.local()
=> #<Gem::Platform:0x1409 @cpu="x86", @os="mswin32", @version="60">

JRuby otoh does seem to do something different

C:\> jruby.exe
irb(main):001:0> require "rubygems"
=> true
irb(main):002:0> Gem::Platform.local()
=> #<Gem::Platform:0xf0 @cpu="universal", @os="java", @version="1.6">

From: ironruby-core-boun...@rubyforge.org 
[mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core] IronRuby version of existing gems

That all depends on how Gem checks the platform.  If it uses the RUBY_PLATFORM 
variable, then IronRuby needs to change what it reports here. Currently, it 
reports i386-mswin32.

--
Will Green
http://hotgazpacho.org/

On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville 
<jdevi...@microsoft.com<mailto:jdevi...@microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion. If 
possible we should prefer platform == “ironruby”, (or .net, do we need to 
differentiate .net and mono?), but accept others.

JD

From: 
ironruby-core-boun...@rubyforge.org<mailto:ironruby-core-boun...@rubyforge.org> 
[mailto:ironruby-core-boun...@rubyforge.org<mailto:ironruby-core-boun...@rubyforge.org>]
 On Behalf Of Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems

This brings a question to mind - what should the general approach be for 
porting existing gems to IronRuby? There could be two possible approaches:

1.       Create a gem with the same name (“win32console” in this case), and 
specify platform==”ironruby”. That way, dependent gems do not need to be 
updated, and users have to remember just one name. IronRuby will use the 
version with platform==”ironruby”, and MRI will use the one with 
platform==”mswin32”. So there should not be any clashes even if you use MRI and 
IronRuby on the same machine.

2.       Create a new gem like iron-term-ansicolor.

Any pro or cons to the two? What should the recommendation be in general?

From: 
ironruby-core-boun...@rubyforge.org<mailto:ironruby-core-boun...@rubyforge.org> 
[mailto:ironruby-core-boun...@rubyforge.org<mailto:ironruby-core-boun...@rubyforge.org>]
 On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released

I released iron-term-ansicolor 0.0.3 last night after testing the gem install 
locally first.

Please let me know if you still have trouble installing it from Rubygems.org.

Also, I've submitted a patch to RSpec to use iron-term-ansicolor if it can, the 
same way it tries to use win32console under MRI.

--
Will Green
http://hotgazpacho.org/


_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core

_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core

Reply via email to