The gem file name does include the platform information. That would seem to imply that gems for different platforms will live in different gem files. I am not too knowledge about the Gem process as well, so I may be incorrect as well…
From: ironruby-core-boun...@rubyforge.org [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Will Green Sent: Friday, March 05, 2010 9:46 AM To: ironruby-core@rubyforge.org Subject: Re: [Ironruby-core] IronRuby version of existing gems I may not fully understand the Gem process here, so please pardon any ignorance. As I understand it, the ability to have separate, per-platform gem files for one Gem name would require that the code for all the platforms is present in the source of the Gem. That way, when you gem install XXX, the XXX library will get compiled locally for your current platform. Or, if the gem author provides them, pre-compiled binaries for your platform. In order to do that, though, I think the source code for multiple platforms needs to be present in the gem source. Luis is very knowledgeable in this area; he also wrote rake-compiler to address this issue with JRuby as well: http://github.com/luislavena/rake-compiler I think it best to get his perspective on the best way to go about this. I am, however, glad that IronRuby is now more truthful about its architecture (since gems compiled for mswin32 WILL NOT WORK on IronRuby). I am certain this will lead to less frustration from end-users going forward. -- Will Green http://hotgazpacho.org/ On Fri, Mar 5, 2010 at 12:00 PM, Shri Borde <shri.bo...@microsoft.com<mailto:shri.bo...@microsoft.com>> wrote: The whole point of changing RbConfig::CONFIG[“arch”] was to be able to have two independent gem files. So you should not need to have to modify Luis Lavena’s code, right? And people installing win32console with MRI should not run any of your code, right? You could certainly drop him a line as a courtesy heads-up… 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: Friday, March 05, 2010 8:11 AM To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org> Subject: Re: [Ironruby-core] IronRuby version of existing gems I'd have to talk to Luis Lavena, the current maintainer of win32console. I might also have to make some code changes or test changes to make the .Net specific stuff a no-op on the C version of Ruby (otherwise, it won't even run). But I'd certainly be open to this. I'll drop him a line this weekend. -- Will Green http://hotgazpacho.org/ On Fri, Mar 5, 2010 at 10:45 AM, Shri Borde <shri.bo...@microsoft.com<mailto:shri.bo...@microsoft.com>> wrote: We should push the change once the dust settles down. Let’s wait until the RTM to make sure that this all actually works as we would like it to. In the meantime, I would encourage all gem authors to play with this and see if there are any issues. “gem build” had the issue mentioned below. Not sure if jeweler etc will have any issues. Will, will you be renaming iron-term-ansicolor to win32console? Its your call whether you want to or not. However, if you do not, we should create a gem with platform=”universal-.net” and with the same name of a native gem, and see what the experience is (does “ir.exe –S gem install” prefer the .NET gem over the native gem?). I did verify that “ir.exe –S gem install win32console” currently does not find any matching gem since the existing win32console is a native gem. 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: Friday, March 05, 2010 7:08 AM To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org> Subject: Re: [Ironruby-core] IronRuby version of existing gems 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<mailto: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<http://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> [mailto: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<mailto: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<mailto:Ironruby-core@rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ 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<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
