Forum: JRuby compiling included "pure" C code for FFI gem

Hi,

I create a gem which includes C code and FFI bindings for it
(https://github.com/colinsurprenant/geokdtree). On JRuby 1.7.2 when
installing the gem it complains with

Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native 
extension
[...]

Native extension support is now disabled by default and the gem
install will work if I set JRUBY_OPTS with -Xcext.enabled=true.

This C code is not Ruby c-ext per se, it is "pure" C, but my gem uses
the gem "extension" support with extconf.rb/mkmf for the install time
compilation etc.

Is there any way to have JRuby compile the included C code in my gem
without requiring users to have to set JRUBY_OPTS?

Thanks,
Colin

--
@colinsurprenant

You might want to checkout ffi-compiler -
https://github.com/ffi/ffi-compiler - it is designed to do exactly
that.

Bingo! Thanks Wayne.

I see it triggers using the Rakefile execution instead of extconf.rb
in the gemspec:
s.extensions << 'ext/Rakefile'

Will JRuby not complain even though cext.enabled is false?

Colin


On Wed, Feb 20, 2013 at 3:40 PM, Wayne Meissner <wmeissner@gmail.com> 
wrote:
>> installing the gem it complains with
>>
>> To unsubscribe from this list, please visit:
>
--
@colinsurprenant

Ok, I'm starting to better understand the actual process with this :P

It is in fact mkmf which triggers the JRuby NotImplementedError: C
extension support is not enabled. error. Nothing to do with the
gemspec extensions hook.

And looking at the ffi-compiler code, awesome work btw!, it will
handle correctly the shared library linking etc etc. So, big thanks
for releasing this and I will refactor my stuff to use it right now.

Also, I had a quick look at your xni gem. Could you explain the
benefits of using xni for a project like mine? Should I expect
performance differences for both JRuby and MRI?  As I understand it,
the process of switch from FFI to xni would involve rewriting all my
bindings?

Thanks,
Colin

On Wed, Feb 20, 2013 at 4:38 PM, Colin Surprenant
<colin.surprenant@gmail.com> wrote:
>
>>> (https://github.com/colinsurprenant/geokdtree). On JRuby 1.7.2 when
>>> compilation etc.
>>> ---------------------------------------------------------------------
>>
>>
>
>
>
> --
> @colinsurprenant



--
@colinsurprenant

On Wed, Feb 20, 2013 at 4:38 PM, Colin Surprenant
<colin.surprenant@gmail.com> wrote:
>
>>> (https://github.com/colinsurprenant/geokdtree). On JRuby 1.7.2 when
>>> compilation etc.
>>> ---------------------------------------------------------------------
>>
>>
>
>
>
> --
> @colinsurprenant



--
@colinsurprenant

Whether XNI is better than FFI+ffi-compiler is a definite "well, it 
depends".

If you just want something that works now, so you can release your gem
to the world, then forget about it and be happy (which is totally
fine, btw), then stick with FFI+ffi-compiler.  Performance will be
much the same as XNI (FFI on JRuby-1.7.x is *really* fast) .  FFI and
ffi-compiler won't be going away any time soon.

On the other hand, if you're looking for something to tinker with, and
want to help shape the way we do C extensions on JRuby to make it
easier, with less boilerplate, then by all means, play with XNI.

Thats really what XNI is about - discovering & tuning the conventions
needed to make C extensions on JRuby easy to get "right", with enough
flexibility to do what 80% of extensions need.   The other 20%
probably need deeper integration, so doing specific implementations
for JRuby and MRI is best.