-
Notifications
You must be signed in to change notification settings - Fork 47
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
Toolchain selection #817
Toolchain selection #817
Conversation
Haven't looked at code in any detail as I'm doing this on my phone. I assume you have included a valid state where there is no toolchain. Instead of checking do we have a toolchain everywhere why don't you create two stages to the extension initialisation one for the toolchain and one for the rest. At initialisation if you have no toolchain you are forced through the select toolchain UI and the rest of the extension doesn't initialize until a toolchain is either downloaded or selected. |
Fair point. I've made it so that the WorkspaceContext doesn't even get created if there's no available toolchain. This allows us to keep relatively the same behaviour as before this patch. However, the command registration now takes an optional WorkspaceContext and will display the toolchain error message if commands are invoked without a WorkspaceContext. I've also moved some of the functionality that doesn't require a toolchain outside of the WorkspaceContext (e.g. the reload extensions notification). |
Co-authored-by: Paul LeMarquand <plemarquand@gmail.com>
So far tested this on macOS (Although I didn't test with multiple Xcode's installed) and works quite well. One minor issue, if you have a local toolchain and then select a new toolchain but set it globally you are still using the original local toolchain. I think you should probably clear the local setting here, or add another dialog to ask do you want to clear it. I'll do a code review later, but I did see a lot of the code is still dealing with possibility of an undefined toolchain, folder context etc, which should be unnecessary now given your description of the changes you made. |
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.
Here is an initial review of code. There is a load of code related to having an optional WorkspaceContext that can be reverted.
We need to make sure we get the UI flow correct for toolchain installation if no toolchain is currently installed.
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.
A few more comments, nothing major.
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.
Two minor nits, apart from that I think we are good
So, I did some more investigation into this. It appears that settings for individual workspace folders are actually ignored for @adam-fowler could you take one more look at the code and see if we're good? |
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 all looks good
I have thought of one issue though, perhaps we can resolve this in another PR
If I select an Xcode install that isn't the Xcode install returned by xcode-select -p
(default). The calls to SwiftToolchain.getLLDB
and SwiftToolchain.getSDKPath
return the wrong paths ie from the default install.
Should we set DEVELOPER_DIR environment var if we are setting the path to an Xcode install to ensure we get the correct LLDB and SDK path
Good catch. I fixed the XCTest path, but did not do the same for these two. I'll merge this PR and have a look at fixing the issue in another PR. |
Fixes #756