OpenJDK reports its version slightly different than Oracle Java, and
this was causing the logic in bin/ruby-build to not detect Java 7 or
higher when OpenJDK was used.
When a target is not found, rbenv-install proposes pulling changes from
upstream. This involves changing the directory to the ruby-build checkout.
This patch adds a '&& cd -' to change the working directory back to where
we've been. Should work on at least Bash and Zsh.
This is to fix the error when installing new gems that have executables
which match existing binstubs in the Rubinius bin directory:
"bundle" from bundler conflicts with PREFIX/gems/bin/bundle
RubyGems is supposed to override the binstub if it detects that the
previous one was also generated by RubyGems for the gem of the same
name, but its detection mechanism gets thrown off by having a double
shebang as a result of our binstubs fixing process.
https://github.com/rubygems/rubygems/blob/v2.2.2/lib/rubygems/installer.rb#L149-L154
This avoids generating binstubs with a double shebang.
Setting CC makes sure that we never have to perform the Darwin-specific
check for whether we should default to `CC=clang` and thus break `uname`
stubs in unrelated tests.
CI never caught this because Travis already has CC set to gcc-4.6.
Newer MRIs will pick up gcc-4.2 from PATH and use that instead of
`/usr/bin/gcc`. While this worked up till now, it will not work in
Yosemite anymore since Homebrew's apple-gcc42 is generally not
compatible with 10.10.
So when CC has not explicitly been set, set it to `clang` to avoid
searching the PATH for any other gcc versions. This fixes MRI builds on
systems where apple-gcc42 is installed.
The definitions that use `require_gcc` are not compatible with Apple's
clang-powered `gcc` and need gcc-4.2 from Homebrew. However, builds
using gcc-4.2 fail on Yosemite with a warning:
couldn't understand kern.osversion `14.0.0'
Although the warning is non-fatal, the build goes to shit from there. It
seems that setting the magical value `MACOSX_DEPLOYMENT_TARGET=10.9`
makes the build work and doesn't seem to have negative consequences.
Because ruby-build is both a Homebrew formula and an rbenv plugin, some
people end up with both installed. In these cases, executing
`rbenv install` vs. `ruby-build` might not use the same install. Users
end up being unsure where `rbenv install` is coming from and upgrading
it from the wrong location.
This detect whether ruby-build is contained in Homebrew or git and shows
upgrade instructions accordingly. Example:
See all available versions with \`rbenv install --list'.
If the version you need is missing, try upgrading ruby-build:
brew update && brew upgrade ruby-build
Stable releases should now be sorted as a higher version than preview
releases or RCs. For instance:
- 1.9.3-preview < 1.9.3-rc1 < 1.9.3-p0
- 2.1.0-dev < 2.1.0-rc1 < 2.1.0
- jruby-1.7.0-preview1 < jruby-1.7.0-rc1 < jruby-1.7.0
It appears that regular `make` that ships on FreeBSD 10 is compatible
enough to build Rubies. This enables ruby-build on fresh FreeBSD
installs (which don't have `gmake` by default) without having to
explicitly set `MAKE=make`.
