Improvements to prebuilt or provided library handling #7496
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
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.
This is useful for identity comparisons to enable replacement library to match against original remote package.
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.
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>`
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).
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.
Only workspace and PubGrub dependency resolver need to know about provided libraries. Post-resolution everything acts based on managed dependencies and package identifiers.
…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.
…ies directly Instead of going through the ManifestLoader machinery and special cases in validator let's just produce mainfest directly.
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.
…container Dependency resolution is switched to use `BoundVersion` to carry provided library information, `.providedLibrary` is fully obsolete.
xedin
commented
Apr 25, 2024
MaxDesiatov
approved these changes
Apr 25, 2024
|
@swift-ci test |
…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.
|
@swift-ci please test |
|
@swift-ci please test Windows platform |
xedin
added a commit
to xedin/sourcekit-lsp
that referenced
this pull request
Apr 26, 2024
[SwiftPM PR](swiftlang/swift-package-manager#7496) consolidates use of provided libraries around Workspace and PubGrub dependency resolver.
|
swiftlang/sourcekit-lsp#1207 |
MaxDesiatov
added a commit
that referenced
this pull request
Jun 26, 2024
Cherry-pick of #7496 and #7433, excluding [16b4142](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.json` and `provided-libraries.json` resources and dropped use of `Bundle` type (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 `main` for 2 months with no known issues. **Testing**: New test cases added and existing ones updated. **Issue**: rdar://125531670 **Reviewer**: @MaxDesiatov and @bnbarham --------- Co-authored-by: Pavel Yaskevich <[email protected]>
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.
Motivation:
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).
Modifications:
Instead of removing packages that are backed by a prebuilt library, dependency resolution marks
BoundVersionassociated with them with aProvidedLibrary(this struct carries information about library location and its metadata).PackageChangeStateis adjusted to reflect a state transition to use a library (unless the package is edited).New
.providedLibrarymanaged dependency is added to handle loading of provided library manifests. Products and targets of the manifests are formed from.swiftmodulesfound in the library location. NewTargetDescription.Kind-.providedLibraryis added to model that (requires only a name and a absolute path to the library root).BinaryTargetbut the structure there was proven too rigid, maybe in the future we could package these libraries as frameworks and it would make things easier.BuildPlanis adjusted to inject-Ito compiler arguments for each library together with-Land-lfor each used target injected into product link arguments.Result:
Provided libraries can now be shipped with a toolchain in
share/pm/<name>location.<name>is aproductNameisprovided-libraries.jsonconfig.