build.mcpp: four channels a rule package had no way to reach the engine through

[Sunrisepeak]

Four channels a rule package had no way to reach the engine through, the layer
above build.mcpp those channels make possible, and the graphics example's half
of raising CI from "builds" to "runs".

Each of the four is small. What they have in common is the shape of the gap: one
side already knew something, and nothing carried it to the side that had to
decide.

mcpp::action gains depfile

An action's inputs are fixed when build.mcpp runs, before its command has
executed. A compiler that learns its include graph by parsing the source
therefore has no channel to report it: editing a file the command merely READ
rebuilds nothing, and mcpp build stays green over a stale artifact.

a.depfile = dep.c_str();
a.arg("--depfile").arg(dep.c_str());

mcpp emits depfile = and deps = gcc for that edge. Every device compiler
this matters for already emits one -- glslangValidator --depfile,
glslc -MD -MF, slangc -depfile, nvcc and clang -MD -MF -- so the
missing half was always the receiving end.

The depfile must not also be a declared output: deps = gcc makes ninja consume
and delete it, so an edge promising it would be permanently dirty. Documented at
the field, at the decoder and at the emission site.

A rule package declares the extensions it compiles, and the module that does it

A constrained glob's accel key does not make a file a device source;
kDeviceExtensions does. Until this change a rule package could not introduce
a device language on its own: measured against 2026.9.6.6 with a working rule
and a working xim:slang, the payload installed, the rule compiled, and the file
still fell through to the ordinary source scan --

warning: [build] accel names vulkan but no constrained glob matched a `.slang`
error: 'scale.slang' is listed in [build] sources, and mcpp has no role for
       the extension '.slang'.

The first version of this branch fixed that by adding .slang to the engine's
table. That inverts the dependency: a general build system would hold a list
of an external plugin's languages, and a third-party rule -- someone else's CUDA
rule, someone else's shader rule -- would still wait on an engine release. The
shape that shipped puts both facts on the rule package's own feature:

[features.rules-slang]
sources           = ["rules/slang.cppm"]
device_extensions = [".slang"]
rule_module       = "mcpp.rules.slang"

The engine holds no package name, no feature spelling and no module name. The
two keys are required together: a feature that claims an extension without
naming who compiles it is refused, rather than letting the file fall out
somewhere later.

The criterion is direct. .slang was removed from kDeviceExtensions, and
mcpp-plugins' tests/slang-consumer builds and runs unchanged. A new device
language now costs no engine release.

Collected after feature activation and before the extension table that narrows
constrained globs, and that position is load-bearing: placed after it, the
declared extensions classify nothing, the device source list comes out empty,
the rule is handed no files, and the failure surfaces three edges away as
failed to read compiled module. Measured.

A project that declares its rules need not write build.mcpp

Once the rule modules are declared, the program's content is determined: import
them, call compile() on each, return non-zero if any refused. mcpp writes it
into the build directory.

A project that takes it over copies the file to its root and edits it, and
synthesis stops -- the declaration is a layer ABOVE build.mcpp, not a second
mechanism beside it. A package that already has one keeps it, because two
programs submitting the same actions is a submission nobody asked for.

A synthesis that cannot write its program now refuses. Returning "nothing to do"
left the device sources handed to no one and the build otherwise successful,
with the first symptom an unresolved name in a consumer three edges away.

[language] modules is reported as MCPP_LANGUAGE_MODULES

A rule that GENERATES a consumer-facing declaration has to choose between a
module interface and a header, and the project has already said which it builds.
Deriving it any other way would be a second spelling of one decision.

An engine that does not report it leaves the variable absent, which a rule reads
as "header" -- the behaviour every consumer had before -- so the upgrade needs no
project to declare anything.

A build program is told which package it is building

MCPP_PKG_NAME and MCPP_PKG_NAMESPACE, read through mcpp::package_name()
and mcpp::package_namespace().

Every name a rule generates is derived from the package's name -- the module a
consumer imports, the namespace the accessors sit in, the symbols in a generated
header -- and nothing answered that question. The closest available answer was
the leaf of MCPP_MANIFEST_DIR, a DIRECTORY name, and the two differ whenever a
package sits under a generic folder. This repository is such a case:
examples/09-heterogeneous/vulkan/app/ declares name = "vulkan-saxpy" and
mcpp.rules.spirv generated app.shaders, which every <something>/app/ in a
workspace would also claim -- and which changes when a folder is renamed.

The e2e distinguishes the two derivations by construction: its fixture's
directory is app and its package is vulkan-saxpy. A fixture whose name
matched its folder passes against either implementation, which is what every
existing one did.

Portability drivers are invisible by default

The Vulkan loader does not hand portability drivers to
vkEnumeratePhysicalDevices unless the instance both enables
VK_KHR_portability_enumeration and sets the matching create-info flag. The
offscreen example now does, so the macOS job runs the render on MoltenVK rather
than only building it, and the example itself declares the driver under
cfg(macos) -- a checkout gets a machine that can run it, not only the runner
that had an extra command.

Asked as a capability rather than as #ifdef __APPLE__: the property is "this
loader is showing me a portability driver", which a Linux machine running a
translation layer also has and a macOS build against a native driver does not.
Linux/lavapipe readings are unchanged, centre pixel (124, 70, 62, 255), device
llvmpipe.

Windows stays at "builds", and the recorded reason was wrong

The run step was written, pushed and measured. xim:mesa-lavapipe installed, the
ICD manifest was found in the store, and the program printed render unavailable -- src/main.cpp reporting that the render function returned
nothing.

An earlier revision of this branch recorded a missing vulkan-1.dll as the
cause. The log refutes it: the Vulkan leg imports vkCreateInstance from that
DLL through the import library, so a process that could not find it would fail
during image load and print nothing at all. It printed. mcpp-index's own
vulkan-tests member calls vkEnumerateInstanceVersion on the windows shards
and passes, which says the same thing from the other side.

A separate measurement removes a second suspect: the Khronos loader in
compat:vulkan cross-builds into a working vulkan-1.dll from the source the
index already carries -- 265 exports matching upstream's vulkan-1.def name for
name, DllMain present, importing only ADVAPI32, CFGMGR32, KERNEL32 and msvcrt.
The descriptor's note argues that a Windows loader must be a DLL, not that it
cannot be built. So a hermetic Windows loader is available whenever it is
wanted, and it is not what this step is waiting on.

What is open is why the lavapipe payload's ICD enumerates no device under a
process mcpp launched. Both notes that carried the wrong cause are corrected in
place rather than deleted, so a reader sees what was believed and what refuted
it.

What is not here

examples/09-heterogeneous moving to the generated boundary and the module
payload surface, which consumes mcpp:plugins 0.3.0. That version needs a
released mcpp to build against, and mcpp's own CI resolves the plugin collection
from the index, so those changes cannot be green until this ships. They are
written, verified on this host against the plugins worktree -- cuda and sycl
build and run on an RTX 4080 with the generated boundary on the island's own
command line, vulkan reaches its SPIR-V as a module -- and parked on
feat/examples-module-surface.