sindoring/moonwell-client-core
1
0
Fork 0
Code Issues Pull Requests 1 Packages Projects Releases 2 Wiki Activity

Every launcher that calls the build stamp gets the 8 MB main stack (#2940)

Browse Source 
The Windows main-thread reserve was set only in `crates/benilla/build.rs`. So `benilla-worldview`, and every launcher built on benilla by the recipe in `extended_launcher.rs`, linked with the linker's default: 1 MB on MSVC, 2 MB on mingw. That is less than the login screen needs.

`benilla_buildstamp::emit()`, which every launcher's build script already calls, now asks for 8 MB through `rustc-link-arg`: `/STACK` on MSVC, `--stack` on mingw. Unlike `rustc-link-arg-bins`, cargo accepts it from a package with no binary, so a library that calls `emit()` still builds. The recipe and CONTRIBUTING's "Building on top" say so.

Test, mingw cross-build: `SizeOfStackReserve` is 0x800000 for `benilla.exe` (unchanged) and `benilla-worldview.exe` (was 0x200000). A library-only crate calling `emit()` checks clean on MSVC and builds on mingw.

Fixes #2934

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Sam Sung
2026-11-01 08:17:05 +07:00
committed by GitHub
parent 383cf93c00
commit 514b7d32b2
5 changed files with 70 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/CONTRIBUTING.md
+5 -4
View File
@@ -40,10 +40,11 @@ taken.
A feature 1.12.1 does not have lives in a crate of its own that adds its Bevy plugins through
`benilla_app::run_with`, as `crates/benilla-app/examples/extended_launcher.rs` shows, or in a
fork. A client started through `run_with` says `extended` in its build line, so its reports read
apart from stock benilla's. The crate keeps its own settings, never rows in benilla's CVar table,
which every addon reads, and its files go under `benilla_app::config_dir()`, its own
`benilla-config/`: an addon it ships is written into that folder's `AddOns/` and loads as any
addon does.
apart from stock benilla's. Its build script calls `benilla_buildstamp::emit()`, which stamps the
commit that line names and gives its binary the 8 MB main-thread stack the app needs on Windows.
The crate keeps its own settings, never rows in benilla's CVar table, which every addon reads,
and its files go under `benilla_app::config_dir()`, its own `benilla-config/`: an addon it ships
is written into that folder's `AddOns/` and loads as any addon does.
Past `run_with` and that folder, benilla opens a piece of itself to such a crate only when its own
1.12.1 work creates that piece, never for the crate alone, and promises no stable API: a crate