How Nox
does the work.

Parse, validate, configure, execute.

nox.build is parsed into one or more project models. The graph validator rejects duplicate targets, missing dependencies, and cycles within the selected project. Setup detects tools and writes nox.state; build reloads that state, orders targets, compiles changed inputs, and links artifacts.

nox.build -> Projects -> Selected project -> Graph -> BuildState
                              -> compile/link/archive

Language details stay at the edge.

C and C++ sources use compiler-generated object and dependency files. Static libraries use the archiver; shared libraries and executables use a compiler driver as linker. Language-qualified executable targets such as executable.rust and executable.cpp preserve explicit intent, while generic executables use source-based Rider selection.

Sources inside one C/C++ target are assigned to worker threads up to -j. Target order remains dependency-ordered even when source compilation is parallel.

Configuration belongs to the build directory.

Each configured directory contains nox.state and separates artifacts by debug or release. nox.config remembers the selected directory for later commands. Changing a toolchain or configuration calls for setup or rebuild; editing a source does not.

build/
  debug/<target>/
  release/<target>/
  nox.state

Builds use argument vectors.

Compiler, linker, archiver, and rustc commands are launched with Command arguments rather than shell strings. Noxfile tasks are intentionally different: Unix tasks run through sh -c, while Windows uses the configured shell or cmd /C.