|
Some checks failed
CI / build-test-release (pull_request) Failing after 44s
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>
|
||
|---|---|---|
| .. | ||
| mylib | ||
| tests | ||
| project.cpp | ||
| README.md | ||
tests
Two ways to write tests, in one project.
cd examples/tests
crafter-build test
Layout:
mylib/MyMath.cppm # the library being tested
project.cpp # declares the library
tests/Smoke/main.cpp # zero-config test (no project.cpp)
tests/UnitMyMath/main.cpp # test that links MyMath and exercises it
tests/UnitMyMath/project.cpp # required for tests with deps
Auto-discovery
Each tests/<Name>/ directory becomes a test. Three layers, escalate only as needed:
tests/<Name>/main.cppwith noproject.cpp— discovery synthesizes a Configuration. Top-level*.cppfiles become implementations,interfaces/*.cppmbecome module interfaces.Smokeis this case.tests/<Name>/project.cpp— full control. Use this when you need defines, dependencies, or non-default targets.UnitMyMathis this case (it depends onMyMath).- Folders starting with
_or.are skipped (e.g.tests/_shared/for cross-test helpers).
Test conventions
- Exit code
0= pass, anything nonzero = fail,77= skipped (autoconf convention). Usestd::exit(77)for runtime skips like "tool not on PATH". - Each test runs in its own subprocess; a segfault doesn't take down the runner.
- Default timeout is 60 s (
crafter-build test --timeout=Noverrides). - Filter by name:
crafter-build test 'Unit*'. List without running:crafter-build test --list.
Linking the parent project
UnitMyMath/project.cpp shows how a test links the project's own library:
cfg.dependencies = { ParentLib("MyMath") };
ParentLib("name") looks up a Configuration* in the parent project (the root project's own config + its dependency graph) by Configuration::name. The fixture's project.cpp can omit cfg.path, cfg.name, etc. — the discovery loop fills folder-derived defaults.
Cross-target test runs
Tests parse --target=... from the project args you pass on the command line:
crafter-build test --target=x86_64-w64-mingw32 --runner=cmd:wine
--runner=<spec> overrides the per-target runner for this invocation. Useful specs: local, cmd:<command> (prefix-exec, e.g. cmd:wine, cmd:qemu-aarch64), ssh:<host>[:<remoteDir>], sshwin:<host>[:<remoteDir>]. Or persist via env var: CRAFTER_BUILD_RUNNER_<normalized_target>=<spec>.