[6.1] Allow workspace options to affect build system search #1952
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
Contributor
bnbarham
commented
Jan 23, 2025
bnbarham
commented
- Explanation: Fixes various cases where workspace options would not affect build system search. Includes some refactoring commits to reduce the number of conflicts.
- Scope: Build system search
- Original PRs: Allow workspace options to affect build system search #1889
- Risk: Low-ish. This does change the way we search for build systems, which is somewhat risky. But it fixes a fairly serious issue when we create implicit workspaces (which caused us to create a new clangd on every request).
- Testing: New test cases to check workspace options impact search
- Reviewers: @ahoppen
We are already logging the options below. (cherry picked from commit 760be31)
(cherry picked from commit 5326852)
(cherry picked from commit 718c0ee)
This was a small refactoring in a much larger PR.
This allows us to clean up the creation of `TestBuildSystem` a little bit because the tests can create `TestBuildSystem` instead of retrieving it from the `BuildSystemManager`. rdar://142906050 (cherry picked from commit 31b1909)
If you have a package located at `/pkg` and a symlink at `/symlink` and you open `/symlink` as a workspace, the SwiftPMBuildSystem’s project root would be `/pkg`. This would mean that it also only knew about build settings for files in `/pkg`, not in `/symlink`. Thus, whenever we were opening a file in `/symlink` we would create an implicit workspace to handle it (but which ended up having a project root at `/symlink` again) – or something close to this. We shouldn’t need to realpath here. If you open `/symlink`, we should view `/symlink` as the project root of your workspace. (cherry picked from commit 8617b8b)
There were a few places that options only took place *after* determining a build system, even though we have multiple that impact the search (eg. `defaultBuildSystem` and `searchPaths`). Additionally track project root and configuration paths separately, so that when searching for implicit workspaces we can make sure to skip creating duplicates. (cherry picked from commit 0c89669)
|
@swift-ci please test |
(cherry picked from commit 44bd97b)
|
@swift-ci please test |
ahoppen
approved these changes
Jan 24, 2025
|
@swift-ci Please test Windows |
|
@swift-ci please test Windows |
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.