[Rubygems-developers] Question on platform, x64
Daniel Berger
djberg96 at gmail.com
Thu Feb 5 19:40:58 EST 2009
Hi,
Luis Lavena wrote:
> On Tue, Jan 27, 2009 at 4:42 PM, Berger, Daniel <Daniel.Berger at qwest.com> wrote:
>> Hi,
<snip>
> There is no way to conditionally tell rubygems that "under this
> platform, please build this extension".
>
>> If there isn't any way to specify that with the Gem::Specification, I would argue that we need some way to do so. Or am I the only person in the world hitting this particular issue?
>>
>
> You're not alone, this imposes a problem for other gems too.
>
> As example, there is a json gem. The json gem take advantage of a C
> extension to parse json output faster, but it also works without it
> with a slower pure-ruby version.
>
> They faced this same problem, and created two gems: json, which forces
> the compilation of the extension and json_pure, which doesn't bundle
> the extension.
>
>> Thanks,
>>
>> Dan
>>
>> PS - Yes, I know I've brought this up before, so sorry if I'm beating the issue to death. If you want to see what I'm dealing with, take a look at the sys-proctable source and tell me how _you_ would bundle the gems.
>
> Beating these issues until death is something good, you've really
> exposed another quirk of RubyGems as package manager that needs to be
> handled to ensure better cross platform integration.
Hm, I noticed the Java gems come out as "universal-java-xxx". That gives
me an idea.
How about this - we add Gem::Specification#universal. It could be false
by default, but if set to true it would result in a gem tagged as
universal. So, instead of "mygem-1.0.0-x86-linux.gem" it would be
"mygem-1.0.0-universal-linux.gem".
Folks on a Linux platform who do "gem install my-gem" would get the
architecture specific gem if there is one. If there isn't one, it would
fall back to the "universal" gem for that platform. If there isn't a
universal gem, then fall back to the standard gem.
Does that seem reasonable?
Regards,
Dan
More information about the Rubygems-developers
mailing list