See http://docs.rubygems.org/read/chapter/20#platform
Basically, most gems contain pure Ruby code. Some gems contain C (or
Java, or now possibly C#) code that gets compiled at gem install time.
Some gems even include pre-compiled code. You will find that the
overwhelming majority of these gems target the mswin32 platform (which
is based on the VC6 runtime).
The reason that binary gems are distributed is that, unlike on most
Linux/UNIX/BSD based systems, Windows does not come with a C compiler,
let alone the specific version used to create mswin32 Ruby, MSVC 6.
So, users of the mswin32 Ruby relied on those who had a license to
MSVC 6 to provide binaries of the gems they needed. This is a major
reason why development of the mswin32 Ruby has ceased... Very few
people have MSVC6, it's old and slow, and those who want MSVC6 (so
they can contribute to mswin32 Ruby) can't get it anymore. This is why
the mingw32 version of Ruby is the actively maintained version of C
Ruby on Windows: no worries about mingw licensing and distribution,
and it's freely available.
This is the reason why it is important that IronRuby report the
correct architecture and runtime environment. As I said before, Gems
that target mswin32 will not run on IronRuby, because the thing that
makes them mswin32 is that they include C extensions that can be, or
are, compiled to native, unmanaged code targetting the MSVC6 runtime.
So, it is important that IronRuby not identify itself as mswin32,
because the gems that target that platform won't work on IronRuby
anyway.
What Luis has done with Rake Compiler is allow the gem author to
create extensions in C and Java, and permit them to compile platform
specific versions of the same gem. I'm sure that he would welcome
contributions that would allow us to write extensions in C# and build
gems that target IronRuby as a platform, all while keeping the same
gem name. That is, win32console-mswin32.gem and win32console-
mingw32.gem come from the same source gem, but they are compiled
against different runtimes, and target different platforms. With
IronRuby identifying itself correctly, and some additions to rake-
compiler to generate .Net assemblies, it may be possible to generate a
win32console-.net20.gem. Even then, we'd need to provide patches to
libraries that use a regex against RUBY_PLATFORM to determine if we're
running on Windows. But then, what if you're running IronRuby on Mono
on Linux, where any of the win32xxx gems make no sense?
My point is that I don't see a way to just inject IronRuby-specific
libraries in place of the mswin32 ones without causing all sorts of
headaches with platform juggling. IronRuby is not always on Windows,
and thus should not identify itself as running on Windows, and
certainly should not identify itself as the MSVC6 version or Ruby.
--
Will Green
http://hotgazpacho.org/
On Mar 5, 2010, at 8:39 PM, Shri Borde <shri.bo...@microsoft.com> wrote:
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> 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 ha
ve to modify Luis Lavena’s code, right? And people installing win32c
onsole 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] On Behalf Of Will Green
Sent: Friday, March 05, 2010 8:11 AM
To: 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> wrote:
We should push the change once the dust settles down. Let’s wait unt
il the RTM to make sure that this all actually works as we would lik
e 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] On Behalf Of Will Green
Sent: Friday, March 05, 2010 7:08 AM
To: 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> 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
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 ot
hers.
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
_______________________________________________
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
