`tar` on OS X auto-detects the type of compression used, so it doesn't
care whether `-z` or `-j` flags were passed to it for extraction.
However, since latest Rubinius archives are compressed with bzip2, we
must handle this distinction explicitly for the sake of other platforms.
fixes#470
Rubinius 2 insists that it installs RubyGems binstubs into
`PREFIX/gems/bin` instead of `PREFIX/bin`.
This creates complexity for rbenv rehash and exec processes, so we
symlink `gems/bin` into `bin` and have RubyGems create binstubs at a
location that is consistent with other Ruby implementations.
See sstephenson/rbenv#178, sstephenson/rbenv#461
This causes tricky issues with Bundler. Bundler assumes that the
configure gem path *only* contains gems. When using this configuration
option, this is not the case.
What happens is that Bundler then removes the path for the Ruby stdlib
from the load path, because it is located inside what is configured as
the gems directory. This then breaks for example Rails applications when
using ruby-build to build Rubinius.
Also see: https://github.com/rubinius/rubinius/issues/2544
if RUBY_BUILD_CACHE_PATH is set, create and maintain a local bare git
repository in this location. The name of the git repository is based
on the git URL, so it will be shared between branches.
The previous version of this logic was causing us to
pass the flag when
* clang is on the PATH, and
* $CC, or 'clang' if CC unset, accepts the flag.
But this is totally wrong if we have clang installed,
haven't set $CC, and are going to end up using gcc.
We end up passing the flag to gcc, which rejects it.
The real fix is to put this in the autoconf goo in MRI
upstream -- the only correct way to decide whether to pass
this flag is after we know exactly what compiler we're using
and can test if that compiler accepts the flag. But we can
do better than before by approximating autoconf's choice of
compiler as $CC if set, 'cc' otherwise (which will typically
be a symlink to gcc or clang or another.)
Fixes: https://github.com/sstephenson/ruby-build/issues/319
and #325, which is a dupe.
