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

Disregard mkrf_conf.rb as a requirement for DevKit #268

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Disregard mkrf_conf.rb as a requirement for DevKit #268

wants to merge 1 commit into from

Conversation

knu
Copy link

@knu knu commented Apr 20, 2015

It has become a common trick to use an extension configure script named mkrf_conf.rb to conditionally install extra dependencies via Gem::DependencyInstaller when installing a gem.

cf. http://en.wikibooks.org/wiki/Ruby_Programming/RubyGems#How_to_install_different_versions_of_gems_depending_on_which_version_of_ruby_the_installee_is_using

A mkrf_conf.rb script is expected to generate a Rakefile which is later run by a standard tool rake(1), and that doesn't necessarily require build tools like make(1), C compiler, etc.

With this change, a gem could even make a dependency on a native gem optional using a mkrf_conf.rb so users on Windows without DevKit could run it.

It has become a common trick to use an extension configure script named `mkrf_conf.rb` to install conditional dependencies via Gem::DependencyInstaller when installing a gem.

cf. http://en.wikibooks.org/wiki/Ruby_Programming/RubyGems#How_to_install_different_versions_of_gems_depending_on_which_version_of_ruby_the_installee_is_using

A `mkrf_conf.rb` script is expected to generate a `Rakefile` which is later run by rake(1), and that doesn't necessarily require build tools like make(1), C compiler, etc.
@Azolo
Copy link
Member

Azolo commented Apr 21, 2015

This is the best solution I've seen yet to this problem.

That being said I'm still a little skeptical of using anything that is in extensions because there's always going to someone, in some place that causes things to fail.

I do think it's a problem though. See #259.

Umm, I'm going to ping @drbrain and @luislavena to see what they think.
There is a very good possibility I may be taking too much caution in my approach.

@drbrain
Copy link

drbrain commented Apr 27, 2015

Why not load the devkit and ignore mkrf extensions at the have_tools check? Or instead issue a warning at the have_tools check?

@Azolo
Copy link
Member

Azolo commented Apr 27, 2015

@drbrain @knu That's actually really good compromise. I would totally accept/merge that.

Thank you for looking at it. 😄

@drbrain I do have a quick question about extensions though. Was the intent to handle that kind of ruby script configuration or is it just a clever work around that people are using since there isn't anything like that in the spec.

@drbrain
Copy link

drbrain commented Apr 28, 2015

It's a clever workaround and is officially unsupported.

@knu
Copy link
Author

knu commented Apr 28, 2015

Actually, installing gems via extensions does not work well with bundler (esp. under bundle --deployment). You'd have to tweak require_paths somehow or import installed library files; either way it is a totally ugly hack.

@Azolo
Copy link
Member

Azolo commented Apr 28, 2015

@knu Alright, well if you find a solution that you like then I'll be glad to help you getting it running on RubyInstaller.

@knu
Copy link
Author

knu commented Apr 30, 2015

What I'm suggesting here is omit the check for devkit when extensions only contain mkrf_conf scripts because make/sh/cc are not a requirement for running a mkrf_conf script. It is out of scope what you do with mkrf_conf.

@Azolo
Copy link
Member

Azolo commented Apr 30, 2015

@knu Sorry, I meant in addition to this change.

For this if could just change the location of the check so that we can fail to load the DevKit THEN check to see if it's just a mkrf_conf script and not fail the entire install.

@johnnyshields
Copy link

As Devkit will be done away with in next release, shall we close this?

@knu
Copy link
Author

knu commented Jun 2, 2017

RubyInstaller2 does not seem to have this problem, so I'm happy with it. Is there any new release from this repo?

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

Successfully merging this pull request may close these issues.

None yet

4 participants