Architecture & build
Evidence basis: source-verified at the pinned commit. Claims on this page were checked by reading the CNA source at commit c1c316b9; unless a sentence says otherwise, nothing here was built or executed.
How the source tree is partitioned into physical modules, which dependencies may point where and how that is enforced, and how configuration, dependencies and tools turn into a build.
Pages in this group
- Configuring CNA per target: routes, toolchains and what a green build proves — How the Linux, Windows (MSVC and MinGW-w64 with Wine), Android, Emscripten and Apple routes configure CNA, run its tests, and what a successful configure, build or test run on each one proves.
- The physical module architecture: ownership, targets and composition — How CNA's 22 framework modules and 12 renderer families own their targets, include roots, tests and examples, which target names cannot be guessed, and how to read a source path at snapshot c1c316b9.
- Module boundaries: cycles, umbrellas and the gates that enforce them — Why CNA keeps three static-archive cycles, what the CNA, CnaExt and BuildConfig compositions carry, what each boundary gate and the fifteen module probes check, when they run and what a violation looks like.
- Dependency acquisition: submodules, siblings, fetched pins and host packages — The five ways outside code enters a CNA build, how they compose, what the configure-time SDL build implies, how host packages change what compiles, the sibling contract and how CNA itself is consumed.
- Tests, examples, presets and tools: what each verdict proves — What a green result from CNA's test corpus, examples, golden images, CMake presets and developer tools actually establishes, sorted by authority class, and how to read a result before citing it.