Rubinius never supported the `--with-libyaml-dir` configure option, so
we can never use `--if needs_yaml` since it's incompatible and might
break the build if libyaml was auto-discovered from Homebrew.
Starting from 2.2.0, Rubinius doesn't even need libyaml anymore since it
stopped building psych. Instead it requires users to install psych as a
gem which vendors its own libyaml anyway.
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.
The TMPDIR check implemented in a4556a73 incorrectly reports that
TMPDIR cannot hold executables on 4.3.11(1) on Ubuntu 14.04.1 LTS.
This is because a script containing no commands returns a non-zero
exit code. Contrast the following:
bash 3.2.53(1) on OS X 10.9.5:
$ bash -c '' && echo SUCCESS
SUCCESS
bash 4.3.11(1) on Ubuntu 14.04.1 LTS:
$ bash -c '' || echo FAIL
FAIL
This patch modifies the test script to explicitly call `exit 0` to
ensure that a successful exit code is returned if the script executes
successfully.
On Fedora, this results in a nice "Fedora 19" identifier and doesn't
show the codename "Schrödinger’s Cat" which is otherwise contained in
`/etc/fedora-release`.
On Arch, this shows "Arch Linux" where previously we had no info for it
(for some reason, `/etc/arch-release` is empty).
http://www.freedesktop.org/software/systemd/man/os-release.html
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
This detects when `/tmp` has been mounted with "noexec" mode and avoids
the cryptic error:
./configure: Permission denied
Hopefully the information provided will be enough for the user to know
that they have to change TMPDIR to another location.
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`.
