Cool beans! I noticed in the latest push that a change was made to Ruby Gems itself:
http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0 Someone should contribute that change to the Ruby Gems project as well. -- Will Green http://hotgazpacho.org/ On Thu, Mar 4, 2010 at 7:36 PM, Shri Borde <shri.bo...@microsoft.com> wrote: > 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> > 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] *On Behalf Of *Shri Borde > *Sent:* Tuesday, March 02, 2010 10:02 AM > *To:* 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] *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 > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > _______________________________________________ > Ironruby-core mailing list > 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
