danielpclark / faster_path

Faster Pathname handling for Ruby written in Rust
MIT License
782 stars 33 forks source link

Bundler extension refactor #71

Closed danielpclark closed 6 years ago

danielpclark commented 8 years ago

The current Bundler extconf.rb implementation has it's rake command error messages swallowed up by the Bundler gem installation system. We need to refactor the extension building to be verbose through Bundler.

Also a way to test a bundle install of the gem in the test suite would be nice.

danielpclark commented 8 years ago

This will help with #18, #20, and #68.

malept commented 8 years ago

Have you considered, instead of using extconf.rb, doing:

spec.extensions << 'ext/Rakefile'

which would have as its default something that looks like build_lib in your root Rakefile.

That's the approach I'm taking for the extensions I'm building with my thermite Rake tasks.

danielpclark commented 8 years ago

Thank you! @malept

I wasn't able to find documentation for using the Rakefile alternative to Makefile. But I did see some code in Bundler that would use it as an alternative.

I'd like to try it out but I will need people with other operating systems to test it out as well.

travisofthenorth commented 8 years ago

Not sure if this is helpful, but the same issue is present when you simply run gem install faster_path.

danielpclark commented 8 years ago

Thank you @travisofthenorth . That does give us a bit more information to work with. It still leaves a lot of unknowns.

malept commented 8 years ago

I'm currently in the middle of figuring out building on Windows, but when I've got that working reasonably (and actually releasing a gem), I'd like to take a crack at integrating thermite with faster_path.

danielpclark commented 8 years ago

@malept Looking into it your gem; is it aimed to be a solution to the problem we're having here?

malept commented 8 years ago

is it aimed to be a solution to the problem we're having here?

Pretty much.

danielpclark commented 8 years ago

Putting notes here for later.

Note: Ruby RVM has a tendency to put libraries in both the gem's lib & ext directory and a platform specific gem directory:

./gems/ruby-2.3.1/gems/ffi-1.9.10/lib/ffi_c.so
./gems/ruby-2.3.1/gems/ffi-1.9.10/ext/ffi_c/ffi_c.so

Which is supportive of jRuby.

And the platform specific:

./gems/ruby-2.3.1/extensions/x86_64-linux/2.3.0/ffi-1.9.10/ffi_c.so

Perhaps we could consider using a standardized ruby path to link the gem. Before that though we would need to place the linked library in each of these locations. Just a thought.