feat(tooling): wire consumers in through Debug::Use and a launcher
A consumer loads Crafter.Debug.Build through
#pragma crafter dependency "<Crafter.Debug>" project "tooling/project.cpp"
and calls Debug::Use in its own CrafterBuildProject, the way
Crafter.LintRules gets in. With the consumer's flag on, Use adds the
library from the checkout the pragma loaded, and writes
build/crafter-debug: a POSIX sh launcher for the client that library
builds. The client is one of the library's dependencies, so a debug
build compiles it in the same pass as the app, from the same sources.
Why a launcher and not a script: every `crafter-build run` loads the
whole project first, which costs 13-28 s per call on 3DForts (a git
pull per unpinned dependency plus rescanning sources), while the
launcher is one sandbox start, 0.08 s. A client built in the Flatpak
links the Flatpak's libc++ against the runtime's glibc, so the launcher
starts it through `flatpak run` and never on the host itself; inside a
CrafterBuild sandbox it runs it directly.
The library, the client and examples/Basic are placeholders that prove
the wiring: the debug build writes a launcher whose client exists, a
plain build has no Crafter::Debug symbols and keeps the notes from
tooling/AGENTS.consumer.md, and a fresh plain build writes a stub that
names the flag.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-01 01:18:07 +01:00
# Basic
feat(examples): Basic, a ball simulation with a bug to find
The example was a placeholder that printed which build it was. It is
now a headless simulation of five balls dropped onto a 10 cm floor
slab at 60 ticks a second, with a bug planted the way such bugs are
written: collision is checked only where each step lands, so the ball
dropped from 60 m, at 34 m/s, steps over the slab and falls forever.
It shows the consumer side end to end:
- Basic.DebugShim forwards Pump, Advance, QuitRequested, Log, Check,
Emit and Sample to Crafter.Debug in debug builds and does nothing in
plain ones, so the simulation and main have no #ifdef but the
session's.
- Basic.DebugCommands, compiled only when Debug::Use returns true,
registers World_Spawn, World_Reset, World_Clear and Ball_Get, and
watches for the physics, the floor and the balls.
- The simulation checks each ball stays above the floor, emits Bounce
and samples the fastest ball, so `pause --on-check`, `wait --event`
and `trace --history` have something to show.
Driven over the real transport, it shows the whole loop: `log --level
warn` names the ball, `pause --on-check` stops the frame it fails,
`set physics.substeps 4` and `call World_Reset` show the fix holds
before any code changes. The plain build simulates ten seconds and
prints that one ball fell through. Its agent notes describe the app
without the bug.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-01 03:22:17 +01:00
A Crafter.Debug example: a headless simulation of balls dropped onto a floor slab, 60 ticks a second.
- **Plain build:** `crafter-build` , run with `crafter-build -r` . It simulates ten seconds as fast as it can and prints how many balls ended up below the floor.
- **Debug build:** this project's debug flag is `--debug-api` and its define `BASIC_DEBUG_API` . The build adds Crafter.Debug, and the app runs in real time until an agent tells it to quit.
## Layout
- `interfaces/Basic.World.cppm` , `implementations/Basic.World.cpp` : the simulation.
- `interfaces/Basic.DebugShim.cppm` : Crafter.Debug's frame-loop and timeline calls, in every build. In the plain build they are stand-ins that do nothing, so the simulation and `main` need no `#ifdef` .
- `interfaces/Basic.DebugCommands.cppm` , `implementations/Basic.DebugCommands.cpp` : the commands and watches, compiled only when `Debug::Use` added Crafter.Debug.
- `implementations/main.cpp` : the loop, with the session under the define.
## Working on Crafter.Debug from here
2026-11-01 18:04:22 +01:00
`project.cpp` loads Crafter.Debug from this checkout (`#pragma crafter dependency "../.."` ), so a change there shows up in the next build here.
