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.
Bats doesn't support both suite-wide setup (in helper) *and* file-wide
setup. Which means the existance of any file-level setup() function
overwrites any setup() function from test_helper. This can be confusing,
and (IMO) easier to simply avoid the overwriting and remove any
_implied_ suite-wide setup function from test_helper.
This turns out to not be so bad for the recently added setup function,
because the only test files that actually need aria2c removed from PATH
are those that actually invoke curl. These can be found because they are
the only test files that stub curl; half of which already had
file-specific setup() functions. So the only ones which need a
file-local setup() function added were: checksum.bats and mirror.bats
Along these lines, rbenv.bats and hooks.bats were removing aria2c from
PATH but don't actually need to. (curl isn't stubbed in these tests so
the existance of aria2c wouldn't affect the tests)
Lastly, fixed a tab/spaces whitespace mixup that was introduced by:
750c086d11
