0.12.0: omit_keys, a named web page, the engine's strip decision, rules-swift, and contributions from the resolved graph - #28
Merged
Merged
Conversation
…symbols reach the packed libraries (#649 E5)
…h a generated header and the Swift runtime on the link (#647 E2)
…n in dist-apk, and rules-swift
…ntribute; one JSON reader for both (#647 E1)
… when keep_debug_symbols cannot restore them (#649 E5)
The repository requires every rule to pass one: swiftc writes the same Makefile-style file clang does, and without it a bridged header could change with no rebuild.
…destination has one claimant Review of the 0.12.0 branch before merge found the graph-contribution merge inconsistent with the precedence its own documentation states. `contributions` is ordered highest priority first: the application's own libraries, then the graph's packages requesters first. The resources merge walks it backwards, so a higher-priority contributor's resource overrides a lower one's through `aapt2 -R`. The assets merge walked it forwards into `collect_tree`, which copies with `overwrite_existing`, so the LAST write won and the deepest dependency decided a file two packages name. Measured on the fixture below: `assets/graph-asset.txt` held `from-the-deeper-library` where the documented order gives `from-the-requester`. The walk is now backwards, for the same reason the resources walk is. `lib/<abi>/` is flat, so the application's own library, an archive's native library of the same name, and a second archive's copy of it all address one file. Each went through `place_library`, which emits a step whose id and output are derived from the ABI and the leaf name: two claimants produced two steps with one id writing one path. One destination now has one claimant, the first in the priority order, and a later claim is reported by name rather than written. `mcpp::plugins::json` decoded each `\u` escape on its own, so a code point above U+FFFF -- which reaches JSON as a surrogate PAIR -- became two three-byte sequences holding unpaired surrogates: not UTF-8, and silently wrong in whatever `AndroidManifest.xml` or `Info.plist` the value was written into. Pairs are now combined, and a surrogate that is not half of one is refused. mcpp's own writer escapes only characters below 0x20 and passes UTF-8 through, so no producer reaches this path today, which is why nothing reported it; the reader is shared by `dist-apk` and `dist-apple` and should not corrupt what it cannot represent. Criterion: `tests/apk-consumer-graph` gains `lib2/`, which `lib/` depends on, so the two contribute one asset name at two distances. Leg (6) reads the packed `assets/graph-asset.txt`. With the walk reverted it fails with `from-the-deeper-library`; with it in place the five legs pass on 2026.9.16.1.
…s run `MCPP_VERSION` moves 2026.9.14.2 -> 2026.9.16.1, the release this collection's 0.12.0 members are written against. The pin is what decides whether a leg runs or reports itself skipped. `tests/apk-consumer` legs (m) and (n) -- `mcpp pack --no-strip` and `--debug-symbols <dir>` reaching the packed libraries -- are gated inside the script on an engine that publishes `MCPP_PACK_STRIP`, so under the old pin they printed `skip: (m),(n) need an engine that publishes MCPP_PACK_STRIP` and the member's central 0.12.0 change had no CI reading at all. It has one now. The step's own comment carried a deferral that had already retired: it said the Android packaging step was not yet green under the pinned version because `kind = "app"` and `mcpp::min_platform_version()` are #622 engine additions. The pin has been above that release since 2026.9.14.2. The note now states what is true, and what the new pin adds.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This pull request is the plugin side of mcpp-community/mcpp#646 to #649, released as 0.12.0. The routing of every item is in mcpp's triage record (
.agents/docs/2026-09-16-646-649-four-issues-by-home.md); what belongs here is what a plugin can implement, and what the engine's new facts make possible.Members
dist-apple:options::omit_keys(#649 P1). A defaulted Info.plist key (UIDeviceFamily,LSRequiresIPhoneOS,NSHighResolutionCapable) can be left out rather than only replaced. A key that is derived, never written, named twice, or also set throughinfo_plistis refused by name.dist-web:options::page(#649 P2). The page file is named by the project,index.htmlby default. A name with a path separator, without.html, or hidden is refused. The side file follows the page name, so a default build is unchanged.dist-apk: the engine's strip decision (#649 E5).MCPP_PACK_STRIPandMCPP_PACK_DEBUG_SYMBOLS_DIR(mcpp 2026.9.16.1+) are read through the environment, so the member keeps working on older engines. Libraries the engine staged are packed as staged, since the engine has already applied--no-stripor--debug-symbolsto them; the member strips only what it stages itself, and says so whenkeep_debug_symbolscannot be honoured because the engine stripped.rules-swift(#647 E2). A package's.swiftsources compile in one whole-moduleswiftcaction into the images the package produces, with a generated Objective-C header for its own C++ units and the Swift runtime search paths and rpath on the link. macOS, the iOS simulator and the iOS device row; every other row is refused by name. Cross-package Swift module imports and SwiftPM are stated as unsupported in the rule's header.dist-apkanddist-apple: contributions from the resolved graph (#647 E1). With mcpp 2026.9.16.1+, every non-root package that states[package.metadata.dist-apk]or[package.metadata.dist-apple]contributes what it declares (Android source roots, resources, assets, a manifest, jars and aars; an Info.plist fragment), resolved against that package's manifest directory and applied in dependency order, with the application's own options last.options::graph_librariesandoptions::graph_info_plistturn the collection off. One JSON reader serves both members.What the review before the release changed
The branch was reviewed once more before mcpp 2026.9.16.1 was tagged. Two findings survived measurement and are the last commit.
contributionsis ordered highest priority first, and the resources merge walks it backwards for that reason. The assets merge walked it forwards into a copy that overwrites, so the deepest dependency decided a file two packages name. Measured on the newtests/apk-consumer-graph/lib2fixture:assets/graph-asset.txtheldfrom-the-deeper-librarywhere the documented order givesfrom-the-requester.lib/<abi>/is flat, so the application's own library, an archive's native library of the same name and a second archive's copy all address one file. Each went throughplace_library, whose step id and output are derived from the ABI and the leaf name, so two claimants produced two steps with one id writing one path. The first claim in the priority order is packed and a later one is reported by name.0x20, so no producer reaches this path today; the reader is shared bydist-apkanddist-apple.Verification
Readings are in the commit messages and in the test scripts.
tests/apk-consumer-graph(new): with 2026.9.16.1 the library's resource reaches the APK,graph_libraries = falseleaves it out, an application resource of the same name wins, and a malformed metadata value is refused naming the package and the key. A fifth leg reads the packedassets/graph-asset.txtand requires the closer of two contributors to decide it; with the walk reverted it fails. With 2026.9.15.2 the same pack succeeds and carries no contribution.tests/apk-consumer: legs (a) to (n), including--no-stripand--debug-symbolsreaching the packed libraries under the new engine.tests/ios-app-consumer: six plan legs foromit_keysand the contributed fragments, including the refusals.tests/web-consumer: a named-page leg beside the default.tests/all-rules-compilecoversrules-swift's module; its execution legs run on macos-15 in this repository's CI.