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
I thought this was not necessary, but a number of people had problems
when linking to OS X's "readline" (actually Editline wrapper):
- Some components of Pry wouldn't work
- Writing literal Unicode characters was not possible #379
- The compilation would downright fail in some cases #82#461Fixes#461
If `-p|--patch` flag was set while invoking `ruby-build` or
`rbenv install`, ruby-build will use `patch -p0 -i -` to apply a patch
from stdin to Ruby, Rubinius, or JRuby source code before running the
rest of `build_package_*` commands.
References #443
Some Rubies need Rake or Bundler for the installation process. However,
since the host Ruby version might not have those gems installed, install
them in a temporary GEM_HOME and add their executables to PATH.
Fixes#426
Previously, if `http get` failed, the `download_tarball` function would
still continue since the ERR trap had no effect at that point.
Given a script in the form of `{ ... } || return 1`, the expressions
that are the part of the first group are not subject to ERR trap since
they are non-last in a chain of expressions.
However, since we still can't count on the ERR trap taking effect in
this phase, better just rewrite the function to manually abort.
Fixes#394
When stub patterns were broken down into an array, they were
accidentally subject to glob expansion. E.g., a pattern '*' might expand
to whatever is in the current directory. This is unwanted, as we need to
preserve patterns as-is.
No more awkward juggling of PATH entries and preset stubs in version
control. Commands are stubbed by symlinking the main stub from a
temporary `$TMP/bin` directory that's added once to PATH in tests.
