Commit b9a1a1fb23 is a revert of commit 8df9a22a85, differing only in the comment.
This means the issue from https://github.com/mruby/mruby/issues/6721 has reappeared.
The cause of https://github.com/mruby/mruby/issues/6721, as stated in the commit message for commit 8df9a22a85, is that each ".o" file has an indirect dependency on all ".pi" files through the presym file.
This patch therefore adds a proxy-like task `gensym:update:#{build.name}` between tasks.
Its purpose is to hide the direct dependency from ".o" files to the presym file from the rake system.
By performing output to presym files after header files, there is no longer a need to check for the existence of header files.
Furthermore, concentrating the file output logic into an "if" block eliminates the need for the `update` variable.
Strict atomicity between presym files and header files is still not guaranteed, as before.
If atomicity is truly required, it can be achieved by deleting the presym file before updating the header files.
Previously, explicit .o => presym.list_path dependencies were only
added for internal builds (mrbc sub-builds). When only a CrossBuild
is configured without an explicit Build.new, the implicit host build
is not internal, so its .o files had no ordering against presym header
generation. This caused "mruby/presym/id.h not found" errors when the
cross build's presym scanning triggered host compilation.
Fixes#6725.
Co-authored-by: Claude <noreply@anthropic.com>
Restrict .o -> presym.list_path dependency to internal builds only
(mrbc sub-build). Regular host/cross builds don't need this because
:all => :gensym ordering guarantees presym headers exist before .o
compilation, and compiler .d files track header changes.
The broad dependency caused full recompilation because Rake's
all_prerequisite_tasks checks transitive prerequisites: every .o
transitively depended on every .pi file through presym.list_path.
Fixes#6721.
Co-authored-by: Claude <noreply@anthropic.com>
Since presym is now always enabled, the @enable_presym flag,
presym_enabled? method, and all conditional branches guarding
presym-specific code paths are dead code. Remove them and
simplify the affected build logic.
Co-authored-by: Claude <noreply@anthropic.com>
Remove disable_presym from mrbc_build and cross-build fallback.
Add explicit object file dependencies on presym headers in
presym.rake to prevent compilation before headers are generated.
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>
Enable -fwasm-exceptions and -sSUPPORT_LONGJMP=wasm for the Emscripten
toolchain. This implements setjmp/longjmp using native WebAssembly
exception handling instructions instead of Asyncify-based emulation.
Benefits:
- Minimal memory overhead (no shadow stack buffer needed)
- No code size penalty
- Works with both C and C++ code
WASM exception handling is supported by all major browsers since 2021-2022
(Chrome 95+, Firefox 100+, Safari 15.2+) and standalone runtimes
(Node.js 17+, Wasmtime, Wasmer).
For older runtimes, users can override with CFLAGS/LDFLAGS environment
variables.
Co-authored-by: Claude <noreply@anthropic.com>
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.
dearblue