This removes the `isolated_gem_dependency` hack as well as the `rake` &
`bundle` shell wrapper functions. The main reason is to avoid having to
use the `command` shell builtin to be able to invoke the real `rake` and
`bundle`. In my testing on bash 3.2, `command` does not respect the
usual bash error handling rules, and thus a failed `command` invocation
can trigger the ERR trap mechanism even when we don't want it to.
This connects the stderr of download utilities like curl and wget to the
original stderr of the process so that they can detect a terminal and
print progress bars to it.
ruby-build now prints the full invocation of (almost) every external
command that it runs. Typically that is something like:
-> ./configure --prefix=/path/to/ruby
-> make -j 2
-> make install
All output of these commands still goes to the log file by default.
This changes the behavior of `--verbose` mode to simply redirect all
command output to the stdout & stderr of the parent process instead of
writing to and then tailing the log file. This allows implementations of
commands like `./configure` or `make` to detect a terminal and output
color.
If a system OpenSSL version was not found or is at version that is incompatible with a Ruby being installed, ruby-build would typically download and compile a new OpenSSL version scoped to that Ruby installation.
Now the `needs_openssl` condition will also check for Homebrew-installed OpenSSL and automatically link to the first one found that satisfies the version requirement. This primarily helps speed up Ruby installation on macOS where the system OpenSSL is never compatible and where Homebrew is a de-facto standard package manager.
- Now only generates a `configure` script if explicitly specified
- Add ability to add arbitrary files to the tarball
- Cache most common tarballs in fixtures directory to speed up tests
The default settings for LDFLAGS and CPPFLAGS were there since the initial commit to ruby-build:
LDFLAGS="-L${PREFIX_PATH}/lib"
CPPFLAGS="-I${PREFIX_PATH}/include"
However, it's not clear to me what these settings help with. A typical Ruby installation will initialize files in these directories, but it will do so regardless of the environment variables.
So, let's remove them and see what breaks.
This was set to gmake in https://github.com/rbenv/ruby-build/pull/1381
as a workaround for https://bugs.ruby-lang.org/issues/16331
YJIT builds in Ruby 3.3 previews require the use of BSD make on these
platforms, and no supported version of MRI requires the use of gmake, so
revert this.
JRuby continues to require gmake for jruby-launcher.
Fixes#2262
Co-authored-by: Mislav Marohnić <git@mislav.net>
This was only used in Ruby versions < 1.9.3, which are now EOL.
This also removes a 11-years old workaround for building Ruby 2.0 with clang.
06d7994bcf
Upon installing their first Ruby version on the system, the user may want to set it as their default; otherwise the default will remain "system" and any `gem install` attempts will fail with a permission error.
This suggestion is skipped if the user already has chosen an explicit default, even if it's "system".
MRI's BigInt use GMP under the hood if available, and if not
fallbacks to an homemade implementation with much worse performance.
Without GMP:
```
>> Benchmark.realtime { Integer('1' * (10 ** 7)) }
=> 13.80743500002427
```
With GMP
```
>> Benchmark.realtime { Integer('1' * (10 ** 7)) }
=> 0.4098639999865554
```
macOS not being a common production platform, it's not a huge deal
but it would still preferable to compile with `gmp.h` if present.
I'd also suggest to print a warning if compiling on macOS and gmp
isn't installed, but I don't know if it's desirable.
NB: `--with-gmp-dir` was only added recently, so this will only
apply to MRI >= 3.2, as well as rubies on which this flag was backported.
* Fixes https://github.com/rbenv/ruby-build/issues/1798
* OpenJDK 17 reports:
$ java -version
openjdk version "17" 2021-09-14
There is no dot in the version, so we need to only use the first match from grep -o.
* Clarify it is a minimum required java version, not an exact version.
* Supports using other GraalVM languages such as JavaScript, Python, R and Java.
* Supports running TruffleRuby on JVM and not only Native.
* Add GraalVM 20.1.0.
"available" implies ruby-build will be checking online sources but
actually ruby-build doesn't do that. "local definitions" may be
prefered.
Pointed out by jasonkarns.
Suggested by mislav: https://github.com/rbenv/ruby-build/pull/1402#discussion_r389060742
> I wonder should we substitute "built-in" with something like "all
> available definitions". Since ruby-build will additionally pick up
> definitions found under the paths listed in RUBY_BUILD_DEFINITIONS,
> these definitions will get listed even if they are not "built-in".
> Therefore, "built-in" feels like a misnomer here.
For the tests to run on FreeBSD, the bash executable needs to be
available in PATH.
The test_helper PATH was modified by
49a9471758 and f70d958f47
in order to be sure that bash is in PATH on FreeBSD.
(The default location for packages on FreeBSD is /usr/local/bin, and
since bash isn't provided by FreeBSD itself, that means /usr/local/bin
is the most common, if not only, location to find bash on FreeBSD.)
However, adding /usr/local/bin to PATH means that homebrew-managed
packages on macOS are now in PATH for the test suite. This is especially
important due to packages like readline. Since ruby-build prefers
homebrew readline when available, this makes the tests fail on macOS
(because the tests are written assuming no readline configuration.)
While the tests could stub brew in all cases, to ensure the readline
package is ignored by the tests, it seems more prudent to revert the
PATH to be as minimal as possible, and to only include /usr/local/bin by
precisely the OS that depends on it.
