V2: WASI, -r flag, CI pipeline, examples & tests cleanup #1
No reviewers
Labels
No labels
bug
claude:done
claude:failed
claude:in-progress
claude:ready
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Catcrafts/Crafter.Build!1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "V2"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
V2 baseline ready for review. Ships:
wasm32-wasip1) target support: auto-sysroot, required compile flags (-fno-exceptions,-mllvm -wasm-enable-sjlj,-D_WASI_EMULATED_SIGNAL),.wasmextension, opt-inEnableWasiBrowserRuntime(cfg)helper that dropsindex.html+runtime.jsnext to the .wasm.-rflag: build-then-run for host targets; auto.exe/.wasmhandling; rejects libraries..forgejo/workflows/ci.yaml): PR/push/dispatch triggers, single arch-latest container, runs tests + cross-compiles for mingw + uploads artifacts; rollinglatestrelease on push to master.wasm32/mingw;-femulated-tlssostd::__once_callableand friends resolve against libstdc++'s emutls definitions;-lstdc++exp -lpthreadauto-linked.GetCrafterBuildHome()exposed from Platform;LoadProject(Linux + Windows) now share the resolution.inner/fixture, no sharedtests/fixtures/tree. NewWasitest verifies.wasmmagic bytes.Test plan
./build.shsucceeds,./bin/crafter-buildself-rebuilds,crafter-build testshows 13 passed / 2 skipped (SshRunner + WindowsViaSsh skip without env vars set)../bin/crafter-build --target=x86_64-w64-mingw32produces a PE32+ executable plus auto-bundled mingw runtime DLLs.index.html+runtime.jswork in a browser (verified via caddy file-server).arch-latestrunner label needs to be registered on the runner before this can run.crafter-build-linux-x86_64.tar.gzandcrafter-build-windows-x86_64.zipupload as workflow artifacts.latestprerelease shows up under Releases with both archives attached.🤖 Generated with Claude Code
WASI / wasm32 target support - Auto-detect /usr/share/wasi-sysroot on Linux when target starts_with("wasm32") - Skip -march/-mtune for wasm (clang rejects them) - Apply -fno-exceptions -fno-c++-static-destructors -mllvm -wasm-enable-sjlj -D_WASI_EMULATED_SIGNAL to wasm builds (compile + std PCM, kept in sync) - .wasm output extension in expectedOutputFor and link command - EnableWasiBrowserRuntime(cfg): opt-in helper that drops index.html + runtime.js next to the .wasm; runtime.js reads window.CRAFTER_WASM_URL set in the templated index.html so a single shim handles any output name -r run flag in the CLI: build then exec the artifact (host targets only; rejects libraries; auto .exe/.wasm extension handling) CI pipeline (.forgejo/workflows/ci.yaml) - Triggers: PR/push to master + manual dispatch - Single arch-latest container job: install deps, bootstrap, self-rebuild, run tests, cross-compile mingw, package both archives, upload artifacts - Rolling 'latest' release published only on push/dispatch to master mingw cross-compile from Linux now works end-to-end: - ExternalDependency cache key includes target so per-target glslang builds don't collide; CMAKE_BUILD_TYPE=Release pinned (otherwise glslang appends 'd' to lib names and breaks linking); cross-compile cmake flags (CMAKE_SYSTEM_NAME=Windows, CMAKE_*_COMPILER_TARGET=...) - project.cpp accepts --target=<triple>; Linux-only -Wl,--export-dynamic and -ldl are gated; mingw glslang skips the standalone exe (its libgcc_eh link pulls pthread which mingw doesn't link by default) - mingw compile uses -femulated-tls so std::__once_callable etc reference the same emutls symbols libstdc++ provides - mingw link auto-adds -lstdc++exp -lpthread GetCrafterBuildHome() exposed from the Platform module; LoadProject (Linux + Windows) now both use it instead of duplicating the resolution. Examples reorg: hello-world, library, with-module, wasi, tests — each with its own README. Tests reorg: per-test directory with inner/ fixture, no shared tests/fixtures/ tree. New Wasi test verifies .wasm magic bytes. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>archlinux:latest slim image has no local pacman master key and an unpopulated upstream keyring, so: - the archlinux-keyring upgrade fails with "no secret key available to sign with" because pacman can't sign the keyring it's rewriting - falling through to -Syu hits the original "unknown trust" errors on libseccomp and zip Run pacman-key --init then --populate archlinux before any pacman -S. This is the documented bootstrap for slim Arch CI containers. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>Setting CRAFTER_BUILD_MARCH=x86-64-v2 made crafter-build emit the mingw cross-compile to bin/crafter.build-exe-x86_64-w64-mingw32-x86-64-v2/ but the package step still hardcoded -native, causing cp to fail. Use ${CRAFTER_BUILD_MARCH} in the path so workflow env and packaging stay in sync. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>Replaces the single Linux + single Windows tarball with six self- contained variants — three µarch levels × two OSes. End users on the Releases page see them as six individually-downloadable archives: crafter-build-{linux,windows}-x86_64-{v2,v3,v4}.{tar.gz,zip} Pick the v-level your CPU supports: v2: SSE4.2 baseline (every x86_64 since ~2011) v3: AVX2 + FMA + BMI (Intel Haswell+, AMD Excavator+, ~2013+) v4: AVX-512 (Skylake-X+, recent server-class) How: the bootstrap binary stays at v2 because the CI SBC (N5105 / Tremont, no AVX) can't execute v3 or v4 instructions and would crash before it could rebuild itself for higher levels. Once bootstrap's done, the same v2 binary is re-invoked with CRAFTER_BUILD_MARCH overridden per variant to produce v2/v3/v4 outputs. Same again with --target=x86_64-w64-mingw32 for the Windows variants. ExternalDependency cache keys on (url, target, march) already so glslang gets built per variant; subsequent CI runs hit the cache. Also drops the wrapper zip from workflow artifacts: instead of one upload-artifact call producing crafter-build.zip containing six archives, there's now one call per archive. The PR / run page shows six small downloads named for what they are. forgejo-release continues to upload release-dir/* as individual assets, so the Releases page already has the right shape — this just brings the workflow artifact UX in line. Bumped the glslang cache key to v2 (one-time invalidation) since the cache layout now needs space for six glslang builds rather than two. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>