The issue resolved by the preceding patch was solely the C++ exception task within the mruby core.
This patch aims to resolve a similar sequencing issue that also exists in GEMS.
In practice, `mruby-compiler` is sometimes loaded via dependencies rather than being explicitly specified in the build configuration file.
In such cases, when `mruby-compiler/mrbgem.rake` is loaded, it is not yet determined whether C++ exceptions will be used. Consequently, even if it later becomes clear that `core/codegen-cxx.cxx` and `core/y.tab-cxx.cxx` are required, the system could not handle this.
To resolve this issue, we introduce the `MRuby::Gem::Specification#build_settings` method as a mechanism for lazily evaluating build setup.
However, for backward compatibility, the commands are cloned twice in `gem.setup` and `gem.setup_build`.
This is because many existing GEMS configure commands directly within the setup block.
ref. https://github.com/mruby/mruby/issues/6615
Until now, GEMs dependent on GEMs described in the build configuration file were loaded and set up after mruby core tasks were defined.
This caused an issue where, if C++ exceptions were enabled later by a dependent GEM, the necessary tasks for mruby core were not defined.
fixed https://github.com/mruby/mruby/issues/6615
Under normal circumstances, `rake -m test` will parallelize not only the build task, but also the test task.
With this patch, `rake -m test:run:serial` will parallelize the build tasks, but the test tasks will be done one by one in sequence.
The name of the task to be added is as follows:
| tasks to be added | corresponding exist tasks
| --------------------- | ----------------
| `test:run:serial` | `test:run`
| `test:run:serial:bin` | `test:run:bin`
| `test:run:serial:lib` | `test:run:lib`
The documentation table is generated by the `rake doc:update-index` command.
The following conditions must be met for links to be added to the documentation table.
- The file must be placed under the `doc/` directory
- The file must have the extension `.md`
- The file must be written at the top of the file with `<! -- summary: ANY-TEXT -->`
Introduce the `MRuby::Build#install_excludes` attribute.
This attribute is an array to which you add strings, regular expressions, and proc objects that will serve as filters to exclude.
This feature was inspired by @hoshiumiarata's comment.
https://github.com/mruby/mruby/issues/6352#issuecomment-2426721517
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`.
If none of the GEMs have `mrblib/` or `src/` directories, generate `mrb_init_mrbgems()` which does nothing, and omit `mrb_final_mrbgems()`.
The impetus was to avoid `gem_funcs[]` becoming a zero-length array, which is not allowed by the C standard.
The problem is caused by #5938.
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()`.
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.
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.
The `xdg-open` command is not available on macOS.
macOS uses the `open` command.
Add info to install doxygen on macOS with Homebrew.
https://formulae.brew.sh/formula/doxygen
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.
After building mruby, if the user compiles and links to `libmruby.a`, expose the included directory of the captured gems.
This is a change to the `<build-dir> /lib/libmruby.flags.mak` file and will result in being added to `bin/mruby-config --cflags`.
This eliminates the need for the user to look up the path and add the compiler flag if the user wants to take advantage of her gems publishing features.
In the main build with `rake CONFIG=...`, there is no problem because it can only be seen from the gems that depends directly and indirectly as before.
However, when compiling independently by the user using `bin/mruby-config`, a header file name collision may occur if a unique header directory is added.
dearblue