[Rubygems-developers] Native Extensions and Pure Ruby Alternatives (again)

Mikel Lindsaar raasdnil at gmail.com
Thu Nov 29 01:03:13 EST 2007

Obviously I have a vested interest in this as I am part of the TMail
maintenance team.
I guess from my viewpoint, you want the install to be as smooth as possible
and as optimistic as possible.

Ideally I would like the following to occur as a default, and I don't think
this is unreasonable.

(1) try to compile the native extensions (going to be the best / fastest in
pretty much every case)

(2) if 1 fails then fall back to a plain ruby version - or at least (in the
case of gems that don't have a ruby version) provide hooks for us to link
into, like display a message that goes "We can't build, I can see you are
running Windows from your environment, would you like to try to download and
install the windows binary version?"

If the user can't compile and wants the native extensions as a binary, then
he/she can gem install name-win32 or name-linux or

This would have the following benefits:

1) Your gem should basically work on anything WITHOUT user intervention.

2) You have a good chance of getting a native binary built first shot

3) The user can choose to download the native binary themselves if they know
how to do it and need it (which implies a certain skill level).

4) You don't have to padd out your gem with a lot of inapplicable binaries
for everyone to download.

5) It would be a lot friendlier and useful than throwing unable to find
nmake messages in the console.

Trans, I think make the patch.  OpenSource is all about scratching your own
itch.  If it is elegant and works then we would be accepted.  Until then,
really, it is just talk without any concrete examples.



On Nov 20, 2007 3:18 PM, Trans <transfire at gmail.com> wrote:

> I'm still trying to figure how to package a project that has native
> extensions but also pure ruby fallbacks.
> My inclination is to have the gem automatically fallback to pure Ruby
> if extension compilation fails. I've even made a patch to RubyGems
> that allows for this, via a settable gemspec option. Would others like
> to see this in RubyGems? Is it worth my effort to submit the patch?
> If not, my only alternative seems to be to separate the native
> extension into a different package. However, I would still like others
> to be able to add the native extension package as a dependency --but a
> non-critical one. That is to say, if the dependency fails to compile,
> I don't want it to halt the installation of the primary package. This
> is important. ActionMailer depends on TMail. But currently it hauls
> around a vendors copy of the pure Ruby version. For it to have an
> external dependency instead it must count on TMail be fault tolerant,
> and not to derail the installation of Rails.
> T.
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20071129/ef5c5e53/attachment-0001.html 

More information about the Rubygems-developers mailing list