[6.0] Improvements to prebuilt/provided library handling #7713
Conversation
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
…load and related methods (cherry picked from commit 6f12e54)
This kind of reference is going to be returned by package resolution if it detects that a provided library version matches all of the constraints. This makes it easier to handle provided libraries post-resolution instead of eliding them completely. (cherry picked from commit 6d0f18e)
This is useful for identity comparisons to enable replacement library to match against original remote package. (cherry picked from commit b88cd88)
(cherry picked from commit 5aa4835) # Conflicts: # Sources/Workspace/Workspace+Manifests.swift
This target points to a prebuilt library that comes from a certain location in a toolchain. It's going to be injected by the package manager into library manifests and shouldn't be accessible via user-facing APIs. (cherry picked from commit 3eb6910)
Location is required down the line for build planning to inject proper header and library includes into the build. The location is currently assumed to be in `share/pm/<productName>` (cherry picked from commit fd7995e) # Conflicts: # Sources/PackageModel/UserToolchain.swift # Sources/SPMTestSupport/MockBuildTestHelper.swift
Instead of eliding provided library packages, start returning them from resolution as a special `.providedLibrary` reference and augment manifest loader to build manifests for such libraries based on contents of the library's directory (each `.swiftmodule` becomes a `.providedLibrary` target). (cherry picked from commit 139c6fa)
Since provided libraries are now returned from resultion we need to double-check if resultion returns proper package reference kinds for packages with provided libraries. (cherry picked from commit 6d7e795)
Only workspace and PubGrub dependency resolver need to know about provided libraries. Post-resolution everything acts based on managed dependencies and package identifiers. (cherry picked from commit 78c68fe) # Conflicts: # Sources/PackageGraph/ModulesGraph.swift # Sources/Workspace/Workspace+Manifests.swift
(cherry picked from commit 04b26ea)
…library First step on the path to remove `ProvidedLibraryPackageContainer` and `PackageReference.providedLibrary` and fix a problem where a package backed by a provided library has to be always treated as "new" or "updated" by `precomputeResolution` which triggers full resolution. (cherry picked from commit bb7f9e7)
…ies directly Instead of going through the ManifestLoader machinery and special cases in validator let's just produce mainfest directly. (cherry picked from commit 2ad3bf2)
All non-edited packages are eligible to use a provided library based on the dependency resolution information. `.usesLibrary` state would result in a new `.providedLibrary` managed dependency injected into workspace state instead of a regular local/remote package. (cherry picked from commit 0486f94)
…container Dependency resolution is switched to use `BoundVersion` to carry provided library information, `.providedLibrary` is fully obsolete. (cherry picked from commit ec680ec)
(cherry picked from commit a76b970) # Conflicts: # Tests/BuildTests/BuildPlanTests.swift
…rovided libraries If a package with a provided library is mentioned in the Package.resolved let's check whether the version of the library matches pinned version of the package and is so, switch to the library. (cherry picked from commit 6a719f4)
(cherry picked from commit 0246381) # Conflicts: # Sources/PackageModel/UserToolchain.swift
|
@swift-ci test |
MaxDesiatov
changed the title
MaxDesiatov
added
build system
bnbarham
approved these changes
Jun 25, 2024
|
@swift-ci test |
|
@swift-ci test windows |
xedin
added a commit
to xedin/swift-package-manager
that referenced
this pull request
Jul 19, 2024
…ftlang#7713)" This reverts commit 001c74a.
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.
Cherry-pick of #7496 and #7433, excluding 16b4142.
Explanation: The idea is to enable provided libraries to be a part of a toolchain, which means that instead of completely eliding them from a package graph, they need to be handled post-resolution in a special way and reflected in a build plan for Swift targets (as compiler and linker arguments). Unified handling of
config.jsonandprovided-libraries.jsonresources and dropped use ofBundletype (config should always be a part of SDK or a toolchain).Scope: Localized, touches modules graph resolution and build planning only in certain configurations.
Risk: Low. While the change has a somewhat broad scope, it's NFC for most builds and has been incubated on
mainfor 2 months with no known issues.Testing: New test cases added and existing ones updated.
Issue: rdar://125531670
Reviewer: @MaxDesiatov and @bnbarham