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`.
The build definitions auto-discovered from rbenv plugins would
previously not appear in `--list` results due to discovery process
taking place too late.
But don't assume that RUBY_BUILD_ROOT is where ruby-build's own files
reside, since RUBY_BUILD_ROOT can be overriden with alternate definition
files location.
Filenames in git diff patches are prefixed by default by "a/" (source)
and "b/" destination. Such patches don't work with ruby-builds `--patch`
option since it internally uses `patch -p0`.
Prior workarounds were to use either an intermediate step:
filterdiff --strip=1
or to generate the patch without the prefix in the first place:
git diff --no-prefix ...
Now, git diff patches are detected by searching for this pattern:
diff --git a/...
And `patch -p1` is used by default in such cases to strip the 1st
component of filename paths.
Fixes#521, closes#484
From patch(1):
-f or --force
Assume that the user knows exactly what he or she is doing, and do not
ask any questions. Skip patches whose headers do not say which file is
to be patched; patch files even though they have the wrong version for
the Prereq: line in the patch; and assume that patches are not reversed
even if they look like they are. This option does not suppress commen-
tary; use -s for that.
Fixes#555
Seems like sed 4.1.5 on RHEL 5.3 doesn't support `-E`, and sed on OS X doesn't
support `-r` to activate the extended regexp mode. Best to avoid extended regexp
altogether for compatibility.
Fixes#495
If there already exists a valid tarball in the build location, e.g. as
artefact of a previous install using `--keep`, don't re-download the
file, as there is no need.
References #487
Previously, curl and wget were instructed to try to resume the download
if the destination file already exists. This is supposed to be done via
the "Range" HTTP header, but doesn't work well with CloudFront:
HTTP server doesn't seem to support byte ranges. Cannot resume.
CloudFront is supposed to support ranges, so I don't know what's going
on here. It might be failing only in case the existing file is a fully
downloaded tarball?
In any case, this disables resuming downloads and resorts to simply
re-downloading the tarball always, overwriting the existing file.
Fixes#487
