Binary gems with precompiled so files for different platforms?

[Robert Feldt]

Hi,

Does RubyGems currently support precompiled binary gems so that I can
make one gem that then unpacks the right versions of the so/dll files
for the platform?

Any tutorial / examples of this?

Regards,

Robert Feldt

 

[Mauricio Fernández]

Hi,

Does RubyGems currently support precompiled binary gems so that I can
make one gem that then unpacks the right versions of the so/dll files
for the platform?

IIRC the canonical way to handle that is creating one gem per platform
and releasing it under a different name.

Any tutorial / examples of this?

One example would be

fxruby-1.2.1-mswin32.gem (win32 bin)
fxruby-1.2.1.gem (source)

 

[Kaspar Schiess]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Feldt wrote:

| Does RubyGems currently support precompiled binary gems so that I can
| make one gem that then unpacks the right versions of the so/dll files
| for the platform?

Rubygems has no trouble with binary files in the newest version. I am
building RMagick as a binary gem for the windows platform and this seems
to work a charm for many people. What is the part that you don't
understand ? Maybe I could give you more specific help than just a
general how-to ?

- --
kaspar

semantics & semiotics
code manufacture

www.tua.ch/ruby
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBLdrPFifl4CA0ImQRAnSJAKCoZjw9+QBXodDk9G9jGBxkuVjwBQCeLlJx
ixUDyszI6rwm/wpLQWAqWd0=
=QWRu
-----END PGP SIGNATURE-----

 

[Robert Feldt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Feldt wrote:

| Does RubyGems currently support precompiled binary gems so that I can
| make one gem that then unpacks the right versions of the so/dll files
| for the platform?

Rubygems has no trouble with binary files in the newest version. I am
building RMagick as a binary gem for the windows platform and this seems
to work a charm for many people. What is the part that you don't
understand ? Maybe I could give you more specific help than just a
general how-to ?

I'm not sure there is something I don't understand...

I want to pack up a gem with precompiled files for linux, windows-cygwin
and windows-mswin32 and have the gem choose at install time which one to
install.

I guess I could go down the route of multiple gems, one for each
platform, (as MF pointed out) but will the command

"gem install --remote myproject"

then know to dl the right one and install it or will the user have to
choose the "right" gem for their platform?

Thanks,

Robert

 

[Curt Hibbs]

Robert Feldt wrote:

| Does RubyGems currently support precompiled binary gems so that I can
| make one gem that then unpacks the right versions of the so/dll files
| for the platform?

Rubygems has no trouble with binary files in the newest version. I am
building RMagick as a binary gem for the windows platform and this seems
to work a charm for many people. What is the part that you don't
understand ? Maybe I could give you more specific help than just a
general how-to ?

- --
kaspar

I believe, the plan for binary RubyGems was to allow you to build separate
binary gems for each platform and the user could then ask for the gem to be
installed using its base name, and RubyGems would automatically select the
correct binary gem for the user's platform (or build from source if no
binary gem was available). I don't know if this has been implemented yet.

Curt

 

[Richard Kilmer]

Robert,

The way this works is the 'platform' attribute of the Gem::Specification
object in your .gemspec. Normally, for pure-Ruby libraries, this is set to
Gem:latform::RUBY. We are gonna release a 0.8.0 version that adds the
ability to specify:

spec.platform = Gem:latform::CURRENT

Which pulls the current platform (from RUBY_PLATFORM) and sets it as a
binary gem. So, on win32, if you do a:

gem build mygem.gemspec

With the cygwin-based Ruby, it will set that as the platfrom (and the name
will be something like mygem-0.1.0-cygwin.gem or soemthing), if you run it
from the standard win32 version it will be named mygem-0.1.0-mswin32.gem.
When you say:

gem install mygem

It will present a list of available platforms (and identify your current
platform) for you to choose from. You could also publish one with the
platform as RUBY and specify:

spec.extensions << 'ext/extconf.rb'

...or wherever your extconf.rb is for the native extension itself and that
will be presented as a source version. If there was no binary version
available for your platform, or you were so inclined to build it for
yourself, you could select the source version of the gem from the list and
it will build the extension upon gem install.

This choosing between platforms will be all operational in 0.8.0 of
rubygems...which should be out within a week.

More doc on the spec format is here:

http://rubygems.rubyforge.org/wiki/wiki.pl?DeveloperGuide

-rich

 

[Robert Feldt]

Robert,

The way this works is the 'platform' attribute of the Gem::Specification
object in your .gemspec. Normally, for pure-Ruby libraries, this is set to
Gem:latform::RUBY. We are gonna release a 0.8.0 version that adds the
ability to specify:

spec.platform = Gem:latform::CURRENT

Which pulls the current platform (from RUBY_PLATFORM) and sets it as a
binary gem. So, on win32, if you do a:

gem build mygem.gemspec

With the cygwin-based Ruby, it will set that as the platfrom (and the name
will be something like mygem-0.1.0-cygwin.gem or soemthing), if you run it
from the standard win32 version it will be named mygem-0.1.0-mswin32.gem.
When you say:

gem install mygem

It will present a list of available platforms (and identify your current
platform) for you to choose from. You could also publish one with the
platform as RUBY and specify:

spec.extensions << 'ext/extconf.rb'

...or wherever your extconf.rb is for the native extension itself and that
will be presented as a source version. If there was no binary version
available for your platform, or you were so inclined to build it for
yourself, you could select the source version of the gem from the list and
it will build the extension upon gem install.

This choosing between platforms will be all operational in 0.8.0 of
rubygems...which should be out within a week.

Thanks for the info; this sounds reasonable. Looking forward to it.

Thanks,

Robert

 

[Gavin Sinclair]

IIRC the canonical way to handle that is creating one gem per platform
and releasing it under a different name.

One example would be

fxruby-1.2.1-mswin32.gem (win32 bin)
fxruby-1.2.1.gem (source)

Unless I'm much mistaken, those gems have the same *name* ('fxruby')
but different *platforms*. The filename is not chosen by the person
building the gem; the filename is not actually important.

Cheers,
Gavin

 

[Chad Fowler]

Unless I'm much mistaken, those gems have the same *name* ('fxruby')
but different *platforms*. The filename is not chosen by the person
building the gem; the filename is not actually important.

That's right. The gem build command uses various conventions to avoid
gems of the same name and different platforms clobbering each other.
But the actual selection of gem to install based on platform uses the
gem's metadata--not it's name. So you could have an fxruby gem named
blah.gem, and it would still get it's platform _and_ name from the
gemspec.

Chad