2009/3/16 Thibaut BarrÃ¨re firstname.lastname@example.org:
Isn’t “platform” used to identify a gem as a JRuby gem? Granted, it’s not
perfect, but having IronRuby gems set the platform to “ironruby” would seem
to make sense with the current state of rubygems. Is there a reason not to
do this, and (other than waiting for changes to rubygems) is there a better
way to accomplish this?
I think it is - although I’m no expert here.
Well it makes sense if we are speaking about a mere reminder that a
gem targets ironruby (it is not really that good, but there is no
other way to do that), but right now it is not possible to enforce
the compatibility with a specific ruby implementation and/or platform
(and this is what I was referring to).
By the way… yes, a few gems just use spec.platform to identify
themselves as jruby gems:
Honestly, the fact that spec.platform was intended for different
purposes does not imply that we should not follow what seems the
de-facto way to overcome the current limits of gemspecs
As well, I’m not sure what setting the “platform” actually implies.
“If this attribute is set to a non-default value, it will be included
in the filename of the gem when it is built, e.g.
See also “gem help platforms”
For instance, I have developed gems that target the MRI. I’m thinking about
adding native support for IronRuby. One example is diacritics_fu
(http://github.com/thbar/diacritics_fu/tree/master) that removes accents
from strings. Under .Net, I can achieve that natively using encoding
stuff. So basically this gem would become usable under both MRI and
IronRuby, it just doesn’t use the same underlying stuff depending on who is
In this case I would simply opt for two separate gems: diacritics_fu
(pure ruby) and diacritics_fu-ironruby. I don’t think that MRI guys
are actually interested in having .NET assemblies in their installed