With my last checkin, RbConfig::CONFIG[“arch”] will be “universal-.net2.0” for
IronRuby. I created a gemspec as shown below. Doing “gem build” on it will
create a gem with filename of Shri-1.2.3-universal-unknown.gem. Instead use
“rbx –S gem build” and you will get a file called Shri-1.2.3-universal-.net.gem.
spec = Gem::Specification.new do |s|
s.name = 'Shri'
s.version = '1.2.3'
s.summary = "Shri summary"
s.platform = "universal-.net"
s.description = %{Shri description}
s.files = []
s.author = "Shri"
s.email = "s...@email"
s.homepage = "http://shri.org";
end
I have updated with
http://ironruby.net/Documentation/Real_Ruby_Applications/RubyGems with this
info:
IronRuby-specific gems
Gems could specifically target IronRuby. They may contain Ruby code which uses
.NET APIs, or they may even include compiled .NET assemblies. In such cases,
the Gem specification should set platform
<http://rubygems.org/read/chapter/20#platform> to "universal-.net" (or
"universal-.net4.0" to run only on .NET 4), and build the gem using IronRuby
("rbx -S gem build").
Note that if you build the gem with MRI using "gem build", MRI will not be able
to recognize the platform string, and will create a gem file named something
like foo-universal-unknown.gem (instead of the expected
foo-universal-.net.gem"). To avoid this, build the gem using IronRuby as
mentioned above.
Talking with Tomas, we will leave RUBY_PLATFORM set to “x86-mswin32” (on
Windows) since many apps check for “mswin32” in RUBY_PLATFORM to check if they
are running on Windows. We considered appending “.net” and setting
RUBY_PLATFORM to “.net-mswin32” or “x86-mswin32/.net” to indicate that it was
not MRI, but decided against it as you can always check RUBY_ENGINE to detect
if you are running on IronRuby.
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
