Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bundler extension refactor #71

Closed
danielpclark opened this issue Jun 20, 2016 · 9 comments
Closed

Bundler extension refactor #71

danielpclark opened this issue Jun 20, 2016 · 9 comments

Comments

@danielpclark
Copy link
Owner

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
Copy link
Owner Author

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

@malept
Copy link
Contributor

malept commented Jun 21, 2016

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
Copy link
Owner Author

danielpclark commented Jun 21, 2016

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
Copy link

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

@danielpclark
Copy link
Owner Author

danielpclark commented Jun 21, 2016

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

@malept
Copy link
Contributor

malept commented Jun 21, 2016

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
Copy link
Owner Author

danielpclark commented Jun 21, 2016

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

@malept
Copy link
Contributor

malept commented Jun 21, 2016

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

Pretty much.

@danielpclark
Copy link
Owner Author

danielpclark commented Jun 22, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants