if MAKE or make are in the environment, use those instead of rbconfig's make. #443
Conversation
make. necessary for those who built ruby with something other than GNU make (gmake is required to build mkmf output)
|
Another workaround for you besides rebuild ruby is to monkey patch rbconfig via $RUBYOPT. |
|
This feels wrong. Why isn't ruby built with the right |
|
mkmf doesn't generate a Makefile compatible with solaris make (or likely anything but gmake). autoconf, however, has no such problem. therefore it's very easy to get into a situation where one builds ruby with a standard OS toolchain that's not compatible with the makefiles typically generated for building extensions. I'd be surprised if anything that doesn't host a gnu toolchain by default (e.g, *BSD) can't be trivially put into this situation. This allows me to point it at gmake instead for building the extensions, no matter how it was built. @raggi's solution is basically the same thing but severely hacking it to avoid a patch that really puts nobody in any danger by default -- they still have to explicitly specify they want to change the make program they want to run. I don't think your concerns about the build environment are an issue because mkmf (again, the common use case) puts a lot of energy into configuring the build environment from rbconfig, so while in theory you may be correct, in practice it's probably not an issue. Additionally, being able to specify it allows me to shoot myself in the foot with cognition instead of asking me to rebuild ruby, where in my specific case I'm depending on packages that have built with this version of make to remain portable (the GNU toolchain is not the standard toolchain on solaris). Alternatively, we could backport make compatibility fixes to mkmf to who knows how far back and release a ton of ruby versions. I don't think that's as reasonable as letting me override make with the environment and using a new version of rubygems, especially because MRI's build system itself doesn't have this issue. Of course, if I do have an issue I'll have to do what you suggest anyway, but at least I have a reasonable option to try first. |
|
I don't see any particular harm in this patch, but I think it should be delayed until after rubygems 2.0, it is too close to ruby 2.0 to include now. |
|
works for me, i just had bandwidth and figured it was safe enough to not be fiddling with for the next two weeks. be well! |
|
hey eric, just wondering, is this acceptable to merge now that the smoke has cleared? |
|
I'd like to wait until the smoke is well-dispersed before adding new features to master. I have this pull request schedule for the next new features release though, perhaps another week or two. |
|
alrighty. thanks for getting back to me. On Thu, Mar 14, 2013 at 8:44 AM, Eric Hodel notifications@github.comwrote:
|
|
This bug hit me as well on Solaris. This would be a win. |
Use MAKE or make from ENV over rbconfig's make.
* pietro-key_passphrase: (154 commits) Update missed tests for rebase of #447 Fixed pull request number type for #461 Improve documentation of DependencyInstaller Alphabetize Gem::DependencyInstaller Removed commented out DependencyInstaller code Alter #489 to use GEM_SPEC_CACHE fix tests when GEM_SPEC is set in environment add support for ENV GEM_SPEC, fix #430 Updated history for #443 Don't alter Gem::Specification.dirs during install Default to Gem.dir as late as possible. Updated history for #455 Update history for #456 Update history for #462 Add tests and alter output of #514 add PATH to gem env Update History for #514 Restore backwards-compatibility for #517 Alphabetize RequestSet Undent RequestSet ... Conflicts: test/rubygems/test_gem_commands_cert_command.rb test/rubygems/test_gem_package.rb
ghost
mentioned this pull request
This is a solution for #426. I don't think there's an easy way to test it but am willing to write them if anyone has a good idea of how to.
It's very easy to get into this situation for non-linux, non-osx users, so I'm hoping this can make it in ASAP. The current situation is "rebuild ruby" for these situations, the converse (where someone has make in their environment and that breaks things because of this change) is much easier to resolve for the end-user, which is why I think this change is pretty safe.