[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-talk
Subject:    Re: Gem with native C for MRI, pure ruby fallback, how to compile?
From:       Samuel Williams <space.ship.traveller () gmail ! com>
Date:       2017-03-24 2:28:05
Message-ID: CAHkN8V8V6Ac1P5zOU6PF=3DBz+m+bQwT+uXoyNXVWfYVLDN8uA () mail ! gmail ! com
[Download RAW message or body]

Well, I definitely think the way native extensions are compiled right
now is a huge mess, after looking at the internals of rubygems and
rake-compiler.

However, I found a solution that basically works and isn't too
cumbersome. https://travis-ci.org/ioquatix/trenni/jobs/214495289 is
finally passing.

This solution leverages rake-compiler.

Simply point `spec.extensions = ["Rakefile"]` and ensure that `rake`
compiles correctly on all the platforms you want. It will be invoked
when installing.

Ideally, you'd probably use "ext/Rakefile" but this breaks on
rake-compiler at present. Perhaps a bug that can be resolved. I
noticed that rake-compiler has to really chop and change the spec file
to get things to build paths set up correctly, which is disappointing.

I think going forward, if Ruby is to embrace a multi-interpreter
world, we need something better, and ideally, simpler. The tie in
between rubygems, mkmf and makefiles and mkmf and all that is huge
impedance mismatch IMHO, when considering different platforms and
interpreters.

A brain dump in no specific order:

1/ I think all the code related to building extensions should be
removed from core rubygems, and it should only have a single command
to build extensions - it could be as simple as gem.extensions =
command_to_run which is invoked using system(*gem.extensions).
convention over configuration and all that.

2/ Platform specific gems are inherently a bad idea IMHO - if we need
pre-compiled gems, it should be as simple as cross-compiling all the
libraries and having them available in ext and handle that when
invoking the command.

3/ Ideally, removing all build and other functionality from
ruby/rubygems, and then growing an eco-system like rake-compiler (but
better in the sense designed from the ground up for multi-platform
multi-interpreter). Gems can expose in their dependencies what they
need to build, and it can be versioned, etc.

Anyway, just my 30 cents. I'd really love to see this area improved
because it really seems like something that we should embrace as a
community - to allow things like jruby and alternative to thrive.


On 24 March 2017 at 11:39, Ryan Davis <ryand-ruby@zenspider.com> wrote:
>
> On Mar 23, 2017, 2:03 PM -0700, Eric Wong <e@80x24.org>, wrote:
>
>
> *Shrug* I don't know. clogger has been doing something similar
> for years:
>
> https://bogomips.org/clogger.git/plain/ext/clogger_ext/extconf.rb
>
> But if I had to do it all over again, I would only have the
> pure Ruby version.
>
>
>
> I've had success using RubyInline and putting C and ruby side-by-side with a
> rescue in-between:
>
> class MyClass
>   begin
>     inline :C do
>       # …
>     end
>   rescue CompilationError
>     def blah
>       # …
>     end
>   end
> end
>
>
>
> Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
>

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

[prev in list] [next in list] [prev in thread] [next in thread]