Gems like mruby-task add preprocessor defines (MRB_USE_TASK_SCHEDULER)
that affect mrb_state structure. The amalgamation generator now detects
these defines from the build configuration and adds them at the top of
mruby.h before struct definitions are encountered.
Supported define patterns: MRB_USE_*, MRB_UTF8_*, HAVE_MRUBY_*
Co-authored-by: Claude <noreply@anthropic.com>
Add ability to generate combined mruby.h and mruby.c files for
single-file embedding, similar to SQLite's amalgamation.
Usage: rake amalgam
Output: build/<target>/amalgam/mruby.{h,c}
Features:
- Headers concatenated in dependency order with guards stripped
- Sources concatenated with proper ordering (core, gems, mrblib)
- X-macro headers (ops.h) inlined at each include point
- Local includes automatically inlined
- Handles both src/ and core/ gem directory conventions
Co-authored-by: Claude <noreply@anthropic.com>
Headers in mrbgems are now categorized into three types:
- src/*.h: gem internal only
- include/*.h: inter-gem use (visible to dependent gems)
- include/export/*.h: external API (exported via mruby-config --cflags)
This prevents internal headers like *_hal.h from being exposed to
external users while maintaining inter-gem header accessibility.
Co-authored-by: Claude <noreply@anthropic.com>
Until now, GEMS added via `gem.add_dependency` retained the last `MRuby::Build.current` from the build configuration file, which was accessible from the top level of `mrbgem.rake`.
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
Replace XML-style markup tags in comments with markdown equivalents:
- <code>...</code> to `...` (inline code)
- <tt>...</tt> to `...` (teletype/monospace)
- <i>...</i> to *...* (italics/emphasis)
- +...+ to `...` (parameter/variable references)
Updated 80+ files across core source, headers, mrbgems, and libraries
to use consistent markdown formatting in documentation comments.
Handled edge cases including special characters like <=> operators.
Co-authored-by: Atlassian Rovo Dev
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
```console
% find -s lib -type f -name '*.rb' -exec ruby -cw {} \;
lib/mruby/build/command.rb:320: warning: `+' after local variable or literal is interpreted as binary operator
lib/mruby/build/command.rb:320: warning: even though it seems like unary operator
Syntax OK
Syntax OK
Syntax OK
Syntax OK
Syntax OK
lib/mruby/gem.rb:469: warning: `&' interpreted as argument prefix
Syntax OK
Syntax OK
Syntax OK
Syntax OK
```
- Added the index number corresponding to the instruction code.
- Omitted trailing `|` from table elements.
The table elements in GitHub Flavored Markdown can't wrap wherever wanted.
And trying to align the end of it tends to make the whole thing longer.
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.
Yukihiro "Matz" Matsumoto