[Rubygems-developers] Platform Specification and Auto-selecting the Platform

Eric Hodel drbrain at segment7.net
Tue Apr 24 19:09:05 EDT 2007

On Apr 23, 2007, at 19:14, Jim Weirich wrote:

> The current situation is that we have essentially two types of
> platforms, Ruby and Win32 right now (is there anything else?).

gems.rubyforge.org'].source_index.map { |_,g| g.platform }.uniq
=> ["ruby", "mswin32", "win32-1.8.2-VC7", nil, "i486-linux", "i586- 
linux", "windows", "i386-mswin32", "i686-darwin8.4.1", "powerpc- 
darwin7.9.0", "powerpc-darwin", "win32-source", "sparc-solaris2.8- 
mq5.3", "i386-mswin32-mq5.3", "unix", "win32-1.8.4-VC6", "java",  
"i686-linux", "i386-linux", "i386-mswin32-mq6"]

> Soon we will be getting gems with a Java / JRuby platform. I'm
> thinking its time to organize that.
> My proposal is to have 3 types of platforms:
> (1) Pure Ruby Platform. Gems in this category can be run using
> just a Ruby runtime (either MRI, Yarv, or JRuby). A good number
> of gems will fall into this category. Pure ruby gems will be
> designated with "ruby" (no designation defaults to a pure ruby
> gem).
> (2) Source Gems. Source gems are gems that come with source code
> that needs to be built (compiled, links, etc) in order to be
> installed. Source code gems will be designated either "C" or
> "Java" depending on the language of the source code. Other
> languages could be supported in the future, but this will do for
> now.
> (3) Binary Gems. Binary gems have the compiled object code
> packaged in the gem. During installation, all you have to do copy
> the libraries (or Jars) to the right location. No compile toolset
> is needed.
> Binary gems will be designed hierarchically as follows:
> (a) Hardwore architecture (e.g. x86, ppc, sparc, jvm).

Don't forget Universal.

> (b) OS (e.g. mswin, linux, macos, bsd, aix)
> (c) Optional OS variant (xp, vista, redhat, ubuntu)
> (d) Optional OS revision.
> So, the binary platform designation for the computer I'm writing
> this on might be: x86-macos-10.4.9. The hardware platform for my
> mail server would be x86-linux-debian-2.4.24. My parallels
> virtual machine might be x86-mswin-xp (I have no idea what
> version of XP I'm running there, but you get the idea). If I were
> running JRuby, the binary platform would be simply "jvm-1.4.2".
> I'm skipping the question of how we can access all this
> information uniformly across all the platforms. Put that down as
> your homework assignment.

It should all be in Config::CONFIG under the TARGET_* values.  Ruby  
implementations should put sensible values in there.  (I've already  
talked with Charles Nutter on this, and I think they've changed  
JRuby's values to be more autoconf-compatible.)

> Now, the platform designation for a gem indicates what
> hareware/os it can run on. So mygem-1.0_jvm-1.4 will run on any
> Java platform with version 1.4 or better. mygem-1.0_x86-macos-10
> will run on any version of MacOS X running on Intel hardware.
> Since you can produce universal binaries on a mac that run on
> either Intel or PowerPC, I would suggest that
> mygem-1.0_uni-macos-10 would be a gem with universal binaries.

I'd rather have everything spelled-out since that's easier to read,  
mygem-1.0-Universal-MacOSX-10.4.  (Is there a defacto standard for  
naming packages like this?)

> (Note that proposed naming scheme for gem file names. Will this
> be a backwards compatibility issue? I don't think so. The gem
> file name is just so we don't have file names for different
> platforms that collide. I suspect that RubyGems will get the real
> platform info from the gemspec itself).

RubyGems shouldn't allow gems to be indexed (repository side) if  
their names don't match their internal metadata.

> So, that's how we designate platforms. How will gems choose a
> platform (more or less) automatically.
> Here's the selection process. Gems will know what platform its
> running on (note to self: do we have to handle cross platform
> installations?).
> [...]
> We will probably need a way to override the default platform
> selection. I would recommend making the override available for
> only explicitly installed gems (not for gems that are installed
> automatically because they are dependencies).

I think the override should apply to all gems installed, rather than  
only explicitly listed gems.  There's at least one Rubyist who has  
gems installed on a disk shared by multiple machines.  Having to  
manually install all dependencies would make automation a real pain.

Also, this change might require changes in the local gem directory's  
name, mygem-1.0-Universal-MacOSX-10.4 instead of mygem-1.0 to allow  
cross-platform gems to live side by side.

More information about the Rubygems-developers mailing list