dist-apple: the staged tree's deployed files land at the bundle's resource destination, and the iOS fixture declares its runtime packages (mcpp#630)

Author: speak-agent

.github/workflows/ci.yml

@@ -1805,7 +1805,16 @@ jobs:
           # hand and got subtly wrong would otherwise fail at launch time on a
           # user's machine and nowhere here.
           plutil -lint "$app/Contents/Info.plist"
-          echo "ok: one bundle, a valid plist, and it launches"
+          # THE DEPLOYED FILE, AT THE RESOURCE DESTINATION AND NOT BESIDE THE
+          # PROGRAM (mcpp#630, item 3a): the engine stages `bin/data/...` and
+          # this member places it under `Contents/Resources/`.
+          test -f "$app/Contents/Resources/data/greeting.txt" \
+            || { echo "FAIL: the deployed file is not under Contents/Resources"; find "$app" -type f; exit 1; }
+          if [ -e "$app/Contents/MacOS/bin" ]; then
+            echo "FAIL: the staged tree was copied whole into Contents/MacOS"; find "$app" -type f; exit 1
+          fi
+          grep -q 'closure = not-walked' pack.log || echo "note: the stage manifest's closure line was not echoed by pack"
+          echo "ok: one bundle, a valid plist, it launches, and the resource is where NSBundle looks"
 
       # THE iOS ROW, FOR REAL (#622 B1's other half). `tests/ios-app-consumer`
       # is the same fixture the Linux `consumers` job checks at the plan
@@ -1868,6 +1877,12 @@ jobs:
           [ "$plat" = "iPhoneSimulator" ] || {
             echo "FAIL: CFBundleSupportedPlatforms is '$plat', expected iPhoneSimulator"
             exit 1; }
+          # THE DEPLOYED FILE, AT THE BUNDLE ROOT (the flat layout), and the
+          # executable at the root by its bare name -- not under `bin/`.
+          test -f "$app/data/greeting.txt" \
+            || { echo "FAIL: the deployed file is not at the bundle root"; find "$app" -type f; exit 1; }
+          test -x "$app/ios-app-consumer" \
+            || { echo "FAIL: the executable is not at the bundle root"; find "$app" -type f; exit 1; }
 
           exe=$(/usr/libexec/PlistBuddy -c 'Print :CFBundleExecutable' "$plist")
           test -x "$app/$exe" \

dist/apple.cppm

@@ -713,16 +713,66 @@ inline plan plan_for(options opt = {}) {
     // one and the program when there is not, and the `inputs` entry is the
     // same either way: the program is what this bundle is FOR, and naming it
     // is what orders this action after the link.
+    //
+    // WITH A STAGED TREE IT COPIES THE PROGRAM, NOT THE TREE. The engine
+    // stages a Mach-O program as `bin/<name>` with every deployed file under
+    // `bin/<to>/...` beside it (mcpp#630, item 3a: staging precedes the
+    // closure walk, and the tree is handed over with `closure = not-walked`
+    // in its manifest). Copying that tree whole into `Contents/MacOS/` put
+    // the executable at `Contents/MacOS/bin/<name>`, which is not where
+    // `CFBundleExecutable` says it is, and the resources beside a program
+    // rather than in `Contents/Resources/`, where `NSBundle` looks. So the
+    // launcher goes to the executable directory by itself, and the staged
+    // `bin/` entries that are not the launcher go to the bundle's resource
+    // destination below, at the relative path `mcpp::deploy`'s `to` gave
+    // them. `${mcpp.stage_dir}` is still named as an input of the launcher
+    // copy, which is what orders every step here after staging and gives
+    // the action its dependency on the tree's manifest.
     layout.argv         = stage.empty()
         ? std::vector<std::string>{ "ditto",
               std::format("${{mcpp.target_file:{}}}", target),
               execDir + "/" + executableName }
-        : std::vector<std::string>{ "ditto", "${mcpp.stage_dir}", execDir };
+        : std::vector<std::string>{ "ditto", launcher, execDir + "/" + executableName };
     layout.inputs       = { std::format("${{mcpp.target_file:{}}}", target) };
+    if (!stage.empty()) layout.inputs.push_back("${mcpp.stage_dir}");
     layout.outputs      = { execDir + "/" + executableName };
     p.steps.push_back(layout);
     assembled.push_back(execDir + "/" + executableName);
 
+    // THE DEPLOYED FILES, AT THE BUNDLE'S RESOURCE DESTINATION.
+    //
+    // Read at plan time against the staged tree, the way `dist-apk` reads
+    // its assets: the second pass of `mcpp pack --format app` runs this
+    // program after the tree is staged, so the entries exist on disk here.
+    // One action per top-level entry under `bin/` that is not the launcher,
+    // a file or a whole directory, each named by its own path so that the
+    // graph carries an edge per deployed thing rather than one edge for
+    // "everything". `ditto <dir> <dir>` copies the source's CONTENTS into
+    // the destination, which is the flat layout iOS wants at the bundle
+    // root and the `Contents/Resources/<to>/` layout macOS wants.
+    if (!stage.empty()) {
+        const std::filesystem::path stageBin = std::filesystem::path(stage) / "bin";
+        const std::filesystem::path launcherPath = std::filesystem::path(launcher);
+        std::error_code ec;
+        std::vector<std::filesystem::path> entries;
+        if (std::filesystem::is_directory(stageBin, ec))
+            for (auto const& e : std::filesystem::directory_iterator(stageBin, ec))
+                if (!ec && e.path() != launcherPath) entries.push_back(e.path());
+        std::ranges::sort(entries);
+        for (auto const& e : entries) {
+            const std::string rel = e.filename().string();
+            step res;
+            res.id          = "mcpp.dist.apple.resource." + rel;
+            res.role        = "artifact";
+            res.description = "APP RESOURCE " + rel;
+            res.argv        = { "ditto", e.string(), resourceDir + "/" + rel };
+            res.inputs      = { e.string(), "${mcpp.stage_dir}" };
+            res.outputs     = { resourceDir + "/" + rel };
+            p.steps.push_back(res);
+            assembled.push_back(resourceDir + "/" + rel);
+        }
+    }
+
     if (!opt.icon.empty()) {
         step icon;
         icon.id          = "mcpp.dist.apple.icon";

tests/app-consumer/mcpp.toml

@@ -23,3 +23,10 @@ plugins = { path = "../..", features = ["dist-apple"], host-module = true }
 [targets.app-consumer]
 kind = "bin"
 main = "src/main.cpp"
+
+# A deployed file, which the bundle must carry at its resource destination
+# (`Contents/Resources/data/greeting.txt` on macOS). The engine stages it at
+# `bin/data/greeting.txt` beside the program (mcpp#630, item 3a), and
+# `dist-apple` places every such entry under the resource directory.
+[runtime]
+deploy = [ { from = "share/greeting.txt", to = "data" } ]

tests/app-consumer/share/greeting.txt

@@ -0,0 +1 @@
+bundled resource

tests/ios-app-consumer/mcpp.toml

@@ -59,6 +59,19 @@ ios_deployment_target = "17.0"
 kind = "bin"
 main = "src/main.cpp"
 
+# THE C++ STANDARD LIBRARY AND THE COMPILER RUNTIME ARE PACKAGES ON THE iOS
+# ROWS (mcpp#630, item 4). The payload's static libc++ is a macOS object and
+# its resource directory carries no iOS builtins archive; without these two
+# lines the engine links the SDK's libc++ under the payload's headers and
+# reports the pairing once. This fixture imports `std`, so it declares them.
+[target.'cfg(os = "ios")'.dependencies]
+llvm.libcxx               = "22.1.8.1"
+llvm.compiler-rt-builtins = "22.1.8.3"
+
+# A deployed file, which the iOS bundle carries at its root (the flat layout).
+[runtime]
+deploy = [ { from = "share/greeting.txt", to = "data" } ]
+
 # THE SIMULATOR ROW ONLY -- the device row (`aarch64-ios`) keeps `runner`
 # unset, as `examples/13-platform-targets/mcpp.toml` does: an artifact cannot
 # be run off an iOS device without a signature the developer owns.

tests/ios-app-consumer/share/greeting.txt

@@ -0,0 +1 @@
+bundled resource