Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid loading xcframeworks as Bundles #3213

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

elliottwilliams
Copy link
Contributor

@elliottwilliams elliottwilliams commented Jun 29, 2021

(NS)Bundle caches bundles as it loads them, so if a loaded bundle's metadata changes during program execution, it will not be reflected by the Bundle API. Carthage does this when it updates a preexisting XCFramework using mergeIntoXCFramework(in:settings:).

This leads to situations where a variant framework inside an XCFramework is "missed" by Carthage and not copied by extractXCFrameworks(in:for:) until carthage build is run a second time. For example, consider the following dependencies:

A: builds for iOS, watchOS
B: depends on A, builds for iOS

When carthage build --use-xcframeworks --platform iOS,watchOS with an empty Carthage/Build directory:

  1. A's watchOS variant builds, and is stored in a new xcframework, Carthage/Build/A.xcframework.
  2. A's iOS variant builds. Carthage loads the Bundle for A.xcframework but does not extract anything (because A.xcframework's Info.plist only indicates watchOS variant frameworks).
  3. B's iOS variant builds. Carthage has already loaded the Bundle for A.xcframework, and does not extract anything (because, as cached by the system, A.xcframework's Info.plist only indicates watchOS variant frameworks). Building B fails.

If I run carthage build --use-xcframeworks --platform iOS,watchOS again, Carthage loads the Bundle for A.xcframework and sees both the watchOS and iOS variants, so building B succeeds.

While there's not an official way to flush the Bundle system's metadata cache, there's a long-standing private CoreFoundation call that does it. We can use that, and assertion-fail in Debug builds if it ever goes away.

It's the only time we expect the bundle metadata to change, so no need
to flush it on every load.
@stale
Copy link

stale bot commented Jan 8, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Jan 8, 2022
@stale stale bot closed this Apr 16, 2022
@jdhealy jdhealy reopened this Feb 8, 2024
@stale stale bot removed the stale label Feb 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants