Symbolic links were created with absolute paths, but to cope with path fluctuations between build and reference, they are now relative paths.
ref. #6084
In #6011, a hexadecimal escape sequence followed by a hexadecimal character would cause a compile error.
Also, avoid using "Numbered Parameter" which older Ruby does not have (e.g. AppVeyor).
ref. #6044
This is a complement to #5928.
The previous PR had the following problem:
- The `<INSTALL_DIR>/bin/*` file could not be replaced if the destination of the symbolic link was lost.
- The wrong link destination was written if `MRuby::Build.install_dir` was a relative path.
Previously, compiler flags were only added for GCC or similar.
The situation has not changed, but it has become easier to improve.
I expect `MRuby::Command::Compiler#setup_debug` to be defined as a singleton method inside the block given to `MRuby::Toolchain.new`.
Make the `mrb_init_mrbgems()` function do the cleanup and error handling.
Instead, simplify processing in the `GENERATED_TMP_mrb_XXX_gem_init()` function.
Previously, `mrb_load_irep()` or `mrb_load_proc()` would kill the process when an exception occurred.
With this patch, it is now caught by `mrb_core_init_protect()`.
The `REnv` object is difficult to deal with, and it would be ideal if the user did not have to manipulate it directly.
In some previous situations, it was necessary to call `mrb_env_unshare()`, a non-API function, after `mrb_load_string()` or similar.
With this patch, it is no longer necessary for users to use `mrb_env_unshare()` directly, as it is now handled internally simply by using the `mrb_vm_ci_env_clear()` function.
Also, `mrb_vm_ci_env_set()` is demoted from the `MRB_API` function for the same reason.
ref. commit 1ab3da6f08
Since `bin/mruby-config` now points to a directory relative to itself, it is no longer possible to reach `include/` or `lib/`.
Therefore, avoid placing entities in them.
This is so that the build directory can be regarded as a temporary installation directory to work in.
Directories set in `MRuby::Gem::Specification#export_include_paths` are used as they are if they are subdirectories placed under `gem.dir`.
Files are placed under `<build-dir>/include/mruby/gems/<gem-name>/<gem-include_paths>` to separate each GEM.
When GEM is compiled by building `libmruby.a`, the same `include_paths` will be set as before, so it is expected that no unintended references will be made.
This was how clone command was previously being generated, for example:
```
git clone --recursive --branch "master" --depth 1 https://github.com/mattn/mruby-onig-regexp.git /path/to mruby with spaces/mruby-3.1.0/build/repos/wasm/mruby-onig-regexp
```
Now it's changed so the path is quoted and will work when containing
spaces:
```
git clone --recursive --branch "master" --depth 1 https://github.com/mattn/mruby-onig-regexp.git "/path/to mruby with spaces/mruby-3.1.0/build/repos/wasm/mruby-onig-regexp"
```
Similar for the other commands.
Allow to update `doc/internal/opcode.md` file mechanically from `include/mruby/ops.h` file.
At the same time, the `doc/internal/opcode.md` file has been updated.
Consecutive hyphens at the end of the table were removed as they would have created noise as markdown flavours.
Exception raising can now be controlled by the caller.
The main purpose on this patch is:
- Suppress exceptions from `obj_free()` in `src/gc.c` with `mrb_env_unshare()`.
- Consider the possibility that calls to `mrb_malloc()` may cause `e` objects to be subject to GC.
When control is returned to `mrb_env_unshare()`, `struct free_obj::next` in the same offset as `struct REnv::stack` is rewritten.
Unexpected results then occur when the object is reused.
Also, if `mrb_heap_page` containing an `e` object is freed, it may cause `SIGSEGV` at that point.
- Protects the value of the stack on `callinfo` that just exits if GC occurs inside `mrb_env_unshare()`.
```ruby
def m
b = -> { b }
end
p m.call
# => print block object, not nil
```
This patch does not raise a `NoMemoryError` exception in `mrb_env_unshare()` and can detect that error.
Thus, the problem fixed in # 3087 is not resurrected.
Also, it may seem that this patch should suppress exceptions raised by `cipop()` during `mrb_protect_error()` and `mrb_vm_exec()` unwinds.
However, `mrb_callinfo::u.env` by `CINFO_DIRECT` is not seen to be set.
So in that case `mrb_env_unshare()` is assumed to be originally exception-free.
The mrbgem guide (`doc/guides/mrbgems.md`) documents the `path:`
argument for `conf.gem` as being used to point to the root directory
of a gem when that gem is retrieved via git but is located in a
subdirectory of the checkout.
The actual code does not do this. Instead, it treats path as (mostly)
identical to the `gemdir:` argument; that is, it points to a local
directory containing the gem.
This change fixes this by making `path:` behave as documented.
This was the cause of the command line flag being affected by changes in the parent build.
So, for example, if `mruby-rational` was included, even the automatically added `mrbc` builds included `MRB_USE_RATIONAL`.
Each build target can be explicitly disabled from benchmarking with `MRuby::Build#disable_benchmark`.
Also, the build target "host", which was previously excluded, is now included in the benchmark.
- Converted LoadGems::load_special_path_gems() into a class, then
subdivided the various types of gem dependencies into smaller
private methods.
- Added class GemDepDetails to hold the relationship between a gem's
location on the local disk and its upstream repository. This will
be used later.
- Removed the last remains of the '--pull-gems' option from the code
base and documentation. This is no longer present and the dead code
is clutter.
Gracefully handle the case where multiple gems use the same git checkout path.
Previously, if two gems had the same directory name when cloning them
from git, mrbgems would assume they were the same gem. This also
applied to different branches and/or commits of the same repository.
This led to a strange situation where the first `conf.gem` statement
"won" in cloning the repository but the last `conf.gem` ended up
choosing the branch/commit-id to use.
This change detects this situation and makes it an error. It also
allows the config writer to explicitly specify a gem checkout to use
in place of the others.
This adds a build_config that will cross-build a Windows executable
using the MinGW cross-compiler and will also run the unit (i.e.
'rake test') using Wine.
For this to work, I made some modifications to the underlying test
scripts as well as some minor changes to a couple of the tests
themselves.
When `disable_cdump` is declared on a Mrbgem spec, the procedure for
loading MRuby code from the gem's `mrblib` directory is slightly
different; instead of loading the mrblib code as a Proc built from the
compiled irep, the compiled irep is loaded directly. The header files
`mruby.h` and `mruby/proc.h` are needed only when the irep is loaded
directly. They are currently included only when presym is disabled, they
should be included whenever either presym is disabled *or* when
`disable_cdump` is called. The `cdump?` predicate method happens to
return true in either case (presym disabled *or* cdump disabled), so
this change should be safe.
dearblue