-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Make the lookup of the PackageDescription dylib fall back on the versioned location if needed #3560
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
Make the lookup of the PackageDescription dylib fall back on the versioned location if needed #3560
Conversation
…ioned location if needed This makes the use of the Manifest API directory (the directory in which PackageDescription.dylib and its interface is located) more robust, so that it works with mismatching toolchains. This is a little tricky to unit-test from inside the codebase, since it involves having an old toolchain compared with the expected one. Existing unit tests make sure there are no regressions.
@swift-ci please smoke test |
@swift-ci please smoke test linux |
return manifestAPIDir | ||
} | ||
|
||
// Otherwise, fall back on the old location (this would indicate that we're using an old toolchain). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we emit some warning in this case, or is it valid?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is valid. It's due to the different locations of PackageDescription, both of which are valid, but are different depending on whether the toolchain has the unified implementation or not.
…e versioned location if needed (swiftlang#3560) This makes the use of the Manifest API directory (the directory in which PackageDescription.dylib and its interface is located) more robust, so that it works with mismatching toolchains. This is a little tricky to unit-test from inside the codebase, since it involves having an old toolchain compared with the expected one. Existing unit tests make sure there are no regressions. (cherry picked from commit 7e0f5e6)
…e versioned location if needed (#3560) (#3567) This makes the use of the Manifest API directory (the directory in which PackageDescription.dylib and its interface is located) more robust, so that it works with mismatching toolchains. This is a little tricky to unit-test from inside the codebase, since it involves having an old toolchain compared with the expected one. Existing unit tests make sure there are no regressions. (cherry picked from commit 7e0f5e6)
This is a follow-on to #3464 that makes the current SwiftPM able to work with libraries from an older toolchain.
This makes the use of the Manifest API directory (the directory in which PackageDescription.dylib and its interface is located) more robust, so that it works with mismatching toolchains. This is a little tricky to unit-test from inside the codebase, since it involves having an old toolchain compared with the expected one. Existing unit tests make sure there are no regressions.
No change in behavior when the SwiftPM and the toolchain libraries match.