Skip to content

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

Conversation

abertelrud
Copy link
Contributor

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.

…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.
@abertelrud abertelrud self-assigned this Jun 16, 2021
@abertelrud
Copy link
Contributor Author

@swift-ci please smoke test

@abertelrud
Copy link
Contributor Author

@swift-ci please smoke test linux

@abertelrud abertelrud added the ready Author believes the PR is ready to be merged & any feedback has been addressed label Jun 18, 2021
return manifestAPIDir
}

// Otherwise, fall back on the old location (this would indicate that we're using an old toolchain).
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@abertelrud abertelrud merged commit 7e0f5e6 into swiftlang:main Jun 21, 2021
abertelrud added a commit to abertelrud/swift-package-manager that referenced this pull request Jun 21, 2021
…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)
abertelrud added a commit that referenced this pull request Jun 22, 2021
…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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready Author believes the PR is ready to be merged & any feedback has been addressed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants