ann-flavor-cocoapods 0.4.3 → 0.4.5

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: eebdd0861c6e897e517afc185dbe5093672eee28a4549ab869aef3105144b72a
-  data.tar.gz: 9976784a3f67eca1be9c0e2ed08bfe2bde6671fe845321dbc39c4b432b90fc46
+  metadata.gz: 308ae984ebc6057da442a37d87cda0ccaa0f110b5044ac8a1a84233390398dfb
+  data.tar.gz: 36e009d9eab357e286766fec9bcd31edc383237c8c17e027843380792f52a0d9
 SHA512:
-  metadata.gz: ada32883a563af3301da9355cfc65fde024ff4a34194e59eaee2a7d6dc863c3d47a2574c3712aebf66e4b4fa29f444b96b70188016fde24810ba8656a975f0d8
-  data.tar.gz: a0691d77e669115cb8ff313d53ad4d4267551ce8c3836fa8101b2e8a5a3342f599552d6cd197f0589a3f52e9e8082dacdd92ea5b7246944c852b69871b70c625
+  metadata.gz: 8efac100a09e6c88be9c283379c2d17f8fac58c3f40281f4f3f87b35f687a89a024595c74839fa80f973236514d87608090498737ff1fb93f79a7d400f6c9dec
+  data.tar.gz: e46fe48609f35471fc48f101e95cc2804d82a7d2fa474cccdeb9f3438f3a06b8215837d7eeb19e844aee1a0604a0709aae0b0a0d56f3bd5e2115126f89a378e9

data/CHANGELOG.md

@@ -1,5 +1,48 @@
 # Changelog
 
+## 0.4.5
+
+### Fixed
+- **0.4.4 stopped the cycle for a *fresh* install, but any project already
+  on 0.4.1-0.4.3 kept hitting it after upgrading.** 0.4.4 stopped *setting*
+  `input_paths` on `[ann-flavor] Merge Entitlements`/`Merge Info.plist`, but
+  never explicitly *cleared* it. `existing = target.build_phases.find { ... }`
+  reuses the same Xcodeproj object across runs, and `pod install` never
+  touches an attribute it doesn't assign — so a project that had already run
+  0.4.1-0.4.3 (which did set `input_paths` on that same, reused object) kept
+  the stale value forever, silently reintroducing the exact "Cycle inside
+  Runner" failure 0.4.4 was meant to remove. Confirmed live against `ledger`:
+  the cycle came back, now involving whichever framework happened to be on
+  the other side of the shared `ModuleVerifierTaskProducer` gate (in this
+  case an SPM-resolved `AppLovinAdapter.xcframework`, following the
+  consumer's separate SPM plugin migration — same underlying mechanism, not
+  a new bug). Fixed by explicitly setting `phase.input_paths = []` on both
+  phases, so a stale value is genuinely wiped on the next `pod install`, not
+  just left unset going forward.
+
+## 0.4.4
+
+### Fixed
+- **"Cycle inside Runner" could still occur even after 0.4.1-0.4.3.**
+  Confirmed live (again, against `ledger`) that declaring `input_paths` on
+  `[CP] Check Pods Manifest.lock`'s own output (introduced in 0.4.1 as the
+  original fix, kept through 0.4.2/0.4.3 as "belt-and-suspenders") was
+  actually the *cause* of the cycle, not a fix for it: `[ann-flavor] Merge
+  Entitlements`/`[ann-flavor] Merge Info.plist`'s output feeds
+  `ProcessProductPackaging` (signing), which Xcode's new build system gates
+  behind a chain of task producers (`ModuleVerifierTaskProducer` et al) —
+  and `Check Pods Manifest.lock`'s own output is *itself* gated behind that
+  same chain. Declaring it as an input routed these phases through that
+  chain from the other direction, closing a genuine cycle with the Firebase
+  framework-copy phases (also gated behind it) regardless of
+  `build_phases` position. Fixed by removing the `input_paths` declaration
+  entirely — `output_paths` plus running after the Pods/framework-copy
+  phases (the 0.4.2 position fix, kept) is sufficient on its own; this
+  phase never actually needed Check Pods Manifest.lock's result as an
+  input. Xcode's own error message ("moving Check Pods Manifest.lock so it
+  runs before the phase that depends on its outputs") was describing a
+  self-inflicted dependency, not a real requirement.
+
 ## 0.4.3
 
 ### Fixed

data/lib/ann_flavor_cocoapods/podfile_helper.rb

@@ -912,10 +912,17 @@ module AnnFlavorCocoapods
       # output_paths) -- suppresses "input file not found" for INFOPLIST_FILE
       # referencing a path nothing else produces until this phase runs.
       phase.output_paths = ['$(DERIVED_FILE_DIR)/Info-merged.plist']
-      # Belt-and-suspenders alongside the append-at-end position fix below --
-      # explicitly orders this phase after CocoaPods' own "[CP] Check Pods
-      # Manifest.lock" phase regardless of list position.
-      phase.input_paths = ['$(DERIVED_FILE_DIR)/Pods-Runner-checkManifestLockResult.txt']
+      # Explicitly cleared, NOT just omitted -- v0.4.1-0.4.3 set input_paths
+      # to Check Pods Manifest.lock's output; v0.4.4 stopped setting it (see
+      # the identical, fuller explanation on inject_merge_entitlements_phase
+      # below for why that declaration was actually the cause of the real
+      # "Cycle inside Runner" failure, not a fix for it), but never explicitly
+      # cleared it -- `existing` reuses the same Xcodeproj object across runs,
+      # so a project that upgraded from 0.4.1-0.4.3 kept the stale value
+      # forever (pod install never touches an attribute it doesn't assign),
+      # silently reintroducing the exact cycle 0.4.4 was meant to fix.
+      # Confirmed live against ledger.
+      phase.input_paths = []
 
       # Appended at the END of build_phases, not unshifted to the front --
       # see the identical, fuller explanation on inject_merge_entitlements_phase
@@ -1027,11 +1034,34 @@ module AnnFlavorCocoapods
       phase.shell_script = script
       phase.show_env_vars_in_log = '0'
       phase.output_paths = ['$(DERIVED_FILE_DIR)/Entitlements-merged.entitlements']
-      # Belt-and-suspenders alongside the append-at-end position fix below --
-      # explicitly orders this phase after CocoaPods' own "[CP] Check Pods
-      # Manifest.lock" phase regardless of list position.
-      phase.input_paths = ['$(DERIVED_FILE_DIR)/Pods-Runner-checkManifestLockResult.txt']
-
+      # NOT declaring input_paths on Check Pods Manifest.lock's own output
+      # here (tried in v0.4.1/0.4.2/0.4.3 as "belt-and-suspenders"). Confirmed
+      # live (yet again, against ledger) that this input_paths declaration is
+      # what CAUSES the real "Cycle inside Runner" failure, not a partial fix
+      # for it: this phase's output feeds ProcessProductPackaging (signing),
+      # which Xcode's new build system gates behind a chain of task producers
+      # (ModuleVerifierTaskProducer et al) — declaring Check Pods Manifest
+      # .lock's result file as this phase's OWN input routes this phase
+      # through that SAME gate chain from the other direction, since Check
+      # Pods Manifest.lock's output is itself gated behind
+      # ModuleVerifierTaskProducer too. The Firebase framework-copy phases
+      # are gated behind that identical chain — closing a genuine cycle no
+      # matter where this phase sits in build_phases. Xcode's own error
+      # message ("moving Check Pods Manifest.lock so it runs before the
+      # phase that depends on its outputs") is describing exactly this
+      # self-inflicted dependency, not a real requirement — this phase never
+      # actually needed Check Pods Manifest.lock's result as an input;
+      # output_paths + running after the Pods/framework-copy phases (via
+      # position, below) is sufficient on its own.
+      #
+      # Explicitly cleared (not just omitted) -- `existing` reuses the same
+      # Xcodeproj object across runs, so a project that upgraded from
+      # 0.4.1-0.4.3 kept the stale input_paths value forever (pod install
+      # never touches an attribute it doesn't assign), silently
+      # reintroducing the exact cycle this fix was meant to remove.
+      # Confirmed live against ledger.
+      phase.input_paths = []
+      #
       # Appended at the END of build_phases, not unshifted to the front.
       # v0.4.1 tried fixing this phase's real "Cycle inside Runner" Xcode
       # build failure (confirmed live against ledger, a project with real

data/lib/ann_flavor_cocoapods/version.rb

@@ -1,3 +1,3 @@
 module AnnFlavorCocoapods
-  VERSION = "0.4.3"
+  VERSION = "0.4.5"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: ann-flavor-cocoapods
 version: !ruby/object:Gem::Version
-  version: 0.4.3
+  version: 0.4.5
 platform: ruby
 authors:
 - ANN Solutions