build.mcpp: a build program is told which package it is building

Found by self-review of the module surface. Every name a rule package
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 in the build-program contract answered that
question. The closest available answer was the leaf of MCPP_MANIFEST_DIR,
which is a directory name.

The two differ whenever a project lays a package out under a generic
folder, and `mcpp.rules.spirv` was measurably wrong there:
`examples/09-heterogeneous/vulkan/app/` declares `name = "vulkan-saxpy"`
and generated `app.shaders`, so every `<something>/app/` in a workspace
claimed one module. A user-facing name derived from a folder is also a
name that changes when a folder is renamed.

MCPP_PKG_NAME and MCPP_PKG_NAMESPACE, with `mcpp::package_name()` and
`mcpp::package_namespace()` reading them. Set at both sites that build a
BuildProgramEnv -- the dependency loop and the root; those two are the
whole enumeration.

The e2e distinguishes the two derivations by construction: the fixture's
directory is `app` and its package is `vulkan-saxpy`, so an implementation
that still read the directory writes `app` where the assertion expects
`vulkan-saxpy`. A fixture whose name matched its folder would pass either
way, which is what every existing one did.

Author: speak-agent

docs/07-build-mcpp.md

@@ -659,6 +659,8 @@ The running program receives the build context as `MCPP_*` variables
 | `MCPP_CXX_STDLIB` *(2026.9.6.3+)* | `mcpp::cxx_stdlib()` | the C++ standard library the resolved toolchain uses — `libstdc++`, `libc++`, `msvc-stl`; empty when no toolchain resolved. A different question from `MCPP_TARGET_LIBC`, which is the C library |
 | `MCPP_ACCEL` *(2026.9.5.2+)* | `mcpp::accel()` | the device axis of this build, resolved — `--accel` / `--no-accel` over `[build] accel` — in the wire form `cuda12.9+{sm_89} ptx>=89`; empty when the build asks for no accelerator. A rule package derives its own flags (`-gencode`, `--offload-arch`) from it, so the architecture set is written once, in the manifest. The same value feeds the `cfg(accelerator = "…")` layer key |
 | `MCPP_LANGUAGE_MODULES` *(2026.9.7.1+)* | -- | `1` when the declaring package sets `[language] modules`, `0` otherwise. A rule that GENERATES a consumer-facing declaration reads it to choose between a module interface and a header, so a project states that once and never again. An older engine leaves it absent, which a rule reads as `0` -- the behaviour every consumer had before the variable existed |
+| `MCPP_PKG_NAME` *(2026.9.7.1+)* | -- | The `[package] name` of the package this program builds. Every name a rule generates is derived from it: the module a consumer imports, the namespace the accessors sit in, the symbols in a generated header. Before it existed the closest available answer was the leaf of `MCPP_MANIFEST_DIR`, which is a directory name -- so a package named `vulkan-saxpy` in a directory named `app` generated `app.shaders`, and every `<something>/app/` in a workspace claimed the same module. Absent under an older engine, which a rule reads as "use whatever you used before" |
+| `MCPP_PKG_NAMESPACE` *(2026.9.7.1+)* | -- | The `[package] namespace`. Empty when the package declares none. A rule that must produce a name unique across an index uses the pair rather than the name alone, because package identity is `(namespace, name)` |
 | `MCPP_DEVICE_SOURCES` *(2026.9.5.2+)* | `mcpp::device_sources()` | the device-kind sources (`.cu`, `.hip`, …) the package's effective `sources` match, package-root-relative, one per line; empty when there are none. The engine compiles none of them — the rule package this program imports turns each into an `mcpp::action`. Already narrowed: a `{ glob, accel }` entry the build does not cover contributes nothing, so `--no-accel` yields an empty list |
 | `MCPP_OUT_DIR` | `mcpp::out_dir()` | a writable scratch/output dir owned by mcpp |
 | `MCPP_MANIFEST_DIR` | `mcpp::manifest_dir()` | the package root (= CWD) |

docs/zh/07-build-mcpp.md

@@ -563,6 +563,8 @@ mcpp 会把它自己构建时用的**同一份** std 模块暂存过来,缓存
 | `MCPP_CXX_STDLIB` *(2026.9.6.3+)* | `mcpp::cxx_stdlib()` | 解析出的工具链使用的 C++ 标准库 —— `libstdc++`、`libc++`、`msvc-stl`;没有工具链解析时为空串。与 `MCPP_TARGET_LIBC` 不是同一个问题,后者是 C 库 |
 | `MCPP_ACCEL` *(2026.9.5.2+)* | `mcpp::accel()` | 本次构建的设备轴,已解析 —— `--accel` / `--no-accel` 优先于 `[build] accel` —— 线上形态 `cuda12.9+{sm_89} ptx>=89`;不要加速器时为空串。规则包从它推导自己的开关(`-gencode`、`--offload-arch`),架构集合因此只在 manifest 写一次。同一个值也喂给 `cfg(accelerator = "…")` 这个 layer 键 |
 | `MCPP_LANGUAGE_MODULES` *(2026.9.7.1+)* | -- | 声明它的那个包设了 `[language] modules` 时为 `1`,否则 `0`。**生成**面向消费者声明的规则读它来在模块接口与头文件之间选择,项目因此只需说一次。旧引擎不设这个变量,规则把缺席读作 `0` —— 也就是这个变量存在之前每个消费者的行为 |
+| `MCPP_PKG_NAME` *(2026.9.7.1+)* | -- | 这个程序所构建的包的 `[package] name`。规则生成的每个名字都由它推导:消费者导入的模块、访问器所在的命名空间、生成头里的符号。在它存在之前,可用的最接近的答案是 `MCPP_MANIFEST_DIR` 的末段,那是目录名 —— 于是一个叫 `vulkan-saxpy` 的包放在名为 `app` 的目录下会生成 `app.shaders`,而工作区里每一个 `<something>/app/` 都声称拥有同一个模块。旧引擎下缺席,规则把缺席读作「沿用你之前用的那个」 |
+| `MCPP_PKG_NAMESPACE` *(2026.9.7.1+)* | -- | `[package] namespace`。包未声明命名空间时为空。需要产出在索引范围内唯一的名字的规则用这一对而不是单用名字,因为包身份是 `(namespace, name)` |
 | `MCPP_DEVICE_SOURCES` *(2026.9.5.2+)* | `mcpp::device_sources()` | 本包有效 `sources` 匹配到的设备类源文件(`.cu`、`.hip`…),相对包根,一行一个;没有时为空串。引擎一个都不编译 —— 由本程序引入的规则包把每一个变成一条 `mcpp::action`。已经过收窄:构建未覆盖的 `{ glob, accel }` 条目贡献为空,因此 `--no-accel` 得到空列表 |
 | `MCPP_OUT_DIR` | `mcpp::out_dir()` | mcpp 提供的可写输出/暂存目录 |
 | `MCPP_MANIFEST_DIR` | `mcpp::manifest_dir()` | 包根(= CWD) |

src/build/build_program.cppm

@@ -124,6 +124,12 @@ struct BuildProgramEnv {
     // (`-gencode`, `--offload-arch`) from here and the architecture set is
     // written once, in the manifest, and never again in a build program.
     std::string accel;
+    // The package this program is building, from `[package]`. Reported because
+    // every name a rule generates is derived from it -- the module a consumer
+    // imports, the namespace its accessors sit in -- and a build program had no
+    // way to ask. See hostprogram::package_name for what it replaced.
+    std::string packageName;
+    std::string packageNamespace;
     // Whether this package builds C++ modules (`[language] modules`).
     //
     // Reported because a rule package that GENERATES a consumer-facing
@@ -522,6 +528,8 @@ contract_env(const fs::path& root, const fs::path& outDir, const BuildProgramEnv
     }
     e.emplace_back("MCPP_OUT_DIR", outDir.string());
     e.emplace_back("MCPP_MANIFEST_DIR", root.string());
+    e.emplace_back("MCPP_PKG_NAME", env.packageName);
+    e.emplace_back("MCPP_PKG_NAMESPACE", env.packageNamespace);
     std::string csv;
     for (auto const& f : env.features) {
         if (!csv.empty()) csv += ',';

src/build/hostprogram.cppm

@@ -375,6 +375,21 @@ inline const char* target_libc_profile()          { return env_or("MCPP_TARGET_L
 inline const char* target_libc()                  { return env_or("MCPP_TARGET_LIBC"); }
 
 inline const char* manifest_dir()                 { return env_or("MCPP_MANIFEST_DIR"); }
+// THE PACKAGE THIS PROGRAM IS BUILDING, BY NAME.
+//
+// A rule package that generates a consumer-facing declaration has to name it,
+// and every name it produces is derived from this one: the module a project
+// imports, the namespace the accessors sit in, the symbols in a generated
+// header. Before these existed the closest thing available was the leaf of
+// `manifest_dir()`, which is a directory name rather than a package name --
+// so a package called `vulkan-saxpy` in a directory called `app` generated
+// `app.shaders`, and every `<something>/app/` in a workspace claimed it.
+//
+// Empty under an engine older than 2026.9.7.1, which a rule reads as "fall
+// back to whatever you did before". That is what keeps an already-published
+// rule package working unchanged.
+inline const char* package_name()                 { return env_or("MCPP_PKG_NAME"); }
+inline const char* package_namespace()            { return env_or("MCPP_PKG_NAMESPACE"); }
 inline bool has_feature(const char* name) {
     char buf[256] = "MCPP_FEATURE_";
     unsigned long o = 13;

src/build/prepare.cppm

@@ -8133,6 +8133,8 @@ prepare_build(bool print_fingerprint,
             // The DECLARING package's setting, not the root project's: a rule
             // generating a declaration for this package must match how this
             // package is compiled.
+            bpEnv.packageName      = pkg.manifest.package.name;
+            bpEnv.packageNamespace = pkg.manifest.package.namespace_;
             bpEnv.languageModules = pkg.manifest.language.modules;
             bpEnv.ruleModules  = pkg.manifest.buildConfig.ruleModules;
             if (auto dit = deviceSourcesByPackage.find(pkg.root.string()); dit != deviceSourcesByPackage.end())
@@ -9059,6 +9061,8 @@ prepare_build(bool print_fingerprint,
         bpEnv.toolsBin = projectSubosBin;
         bpEnv.profile      = effectiveProfile;
         bpEnv.accel        = resolvedAccel();
+        bpEnv.packageName      = m->package.name;
+        bpEnv.packageNamespace = m->package.namespace_;
         bpEnv.languageModules = m->language.modules;
         bpEnv.ruleModules  = m->buildConfig.ruleModules;
         if (auto dit = deviceSourcesByPackage.find(root->string()); dit != deviceSourcesByPackage.end())

tests/e2e/632_a_build_program_is_told_its_package_name.sh

@@ -0,0 +1,82 @@
+#!/usr/bin/env bash
+# requires: gcc
+# A BUILD PROGRAM IS TOLD WHICH PACKAGE IT IS BUILDING.
+#
+# Every name a rule package generates is derived from this one: the module a
+# consumer imports, the namespace the accessors sit in, the symbols in a
+# generated header. Until 2026.9.7.1 nothing answered it, and the closest thing
+# available was the leaf of `MCPP_MANIFEST_DIR` -- a DIRECTORY name.
+#
+# THE DIRECTORY AND THE PACKAGE ARE DELIBERATELY DIFFERENT HERE, and that is the
+# whole test. A fixture whose package name happens to equal its directory leaf
+# passes against both the old derivation and the new one, so it would assert
+# nothing. `mcpp.rules.spirv` shipped with exactly that defect: an example laid
+# out as `vulkan/app/` with `name = "vulkan-saxpy"` generated `app.shaders`, and
+# every `<something>/app/` in a workspace claimed the same module.
+#
+# The answer is written to a FILE rather than printed, because mcpp shows a
+# build program's stdout only when it exits non-zero -- a criterion reading the
+# build log would be measuring the failure path.
+set -e
+
+TMP=$(mktemp -d)
+trap "rm -rf $TMP" EXIT
+cd "$TMP"
+
+# The directory is `app`. The package is not.
+mkdir -p app/src
+cat > app/src/main.cpp <<'EOF'
+int main() { return 0; }
+EOF
+
+cat > app/build.mcpp <<'EOF'
+#include <cstdio>
+#include <string>
+import mcpp;
+int main() {
+    std::string out = std::string(mcpp::manifest_dir()) + "/answered.txt";
+    std::FILE* f = std::fopen(out.c_str(), "w");
+    if (f == nullptr) return 3;
+    std::fprintf(f, "name=%s\n", mcpp::package_name());
+    std::fprintf(f, "namespace=%s\n", mcpp::package_namespace());
+    std::fclose(f);
+    return 0;
+}
+EOF
+
+cat > app/mcpp.toml <<'EOF'
+[package]
+name      = "vulkan-saxpy"
+namespace = "example"
+version   = "0.1.0"
+
+[build]
+sources = ["src/*.cpp"]
+
+[targets.vulkan-saxpy]
+kind = "bin"
+main = "src/main.cpp"
+EOF
+
+cd app
+"${MCPP:-mcpp}" build > build.log 2>&1 || { echo "FAIL: build"; cat build.log; exit 1; }
+
+[ -f answered.txt ] || { echo "FAIL: the build program wrote no answer"; exit 1; }
+cat answered.txt
+
+grep -qx 'name=vulkan-saxpy' answered.txt || {
+    echo "FAIL: package_name() did not answer the [package] name"
+    echo "      (a directory-derived answer would read 'app')"
+    exit 1; }
+grep -qx 'namespace=example' answered.txt || {
+    echo "FAIL: package_namespace() did not answer the [package] namespace"
+    exit 1; }
+
+# THE REVERSE LEG: the directory leaf is `app`, so an implementation that still
+# derived from the directory would have written `app` above. Assert the two are
+# actually different in this fixture, or the check above proves nothing.
+[ "$(basename "$PWD")" = "app" ] || {
+    echo "FAIL: this fixture no longer distinguishes the two derivations"
+    exit 1; }
+
+echo "PASS: a build program reads its package identity, not its directory name"