swiftlang / vscode-swift

Visual Studio Code Extension for Swift
https://marketplace.visualstudio.com/items?itemName=sswg.swift-lang
Apache License 2.0
704 stars 46 forks source link

Confusing which Xcode I'm using with a nightly toolchain #911

Open dschaefer2 opened 1 week ago

dschaefer2 commented 1 week ago

Now that Xcode 16 Beta is out I have two Xcodes installed on my machine. I have also downloaded the nightly build of the 6.0 Swift toolchain. Sometimes I want to use it with Xcode 15, sometimes with Xcode 16 Beta. When I use the command to select a Swift toolchain it's confusing which Xcode it's actually using. It would be nice if I could select that separately from the toolchain selection. At the end of they day, they are different environment variables on Mac, DEVELOPER_DIR and TOOLCHAINS.

adam-fowler commented 1 week ago

When you select an Xcode installation you are selecting the toolchain from that Xcode install. If you select a toolchain install it isn't using your Xcode install at all, outside of one thing, the xctest library. I'm not certain offhand which Xcode version of xctest it would be using. Maybe @matthewbastien who wrote the toolchain select can answer that.

If you are using swift-testing selecting a toolchain install should mean you aren't using an Xcode install at all. In theory you shouldn't even need Xcode installed. I haven't tested that though.

We are not using the DEVELOPER_DIR or TOOLCHAINS environment variables.

plemarquand commented 1 week ago

Just for clarity, swift-testing is included in the Xcode 16 Beta. This means that if you are using Xcode and then switch to a toolchain install you may need to explicitly specify swift-testing as a dependency.

adam-fowler commented 1 week ago

Just for clarity, swift-testing is included in the Xcode 16 Beta. This means that if you are using Xcode and then switch to a toolchain install you may need to explicitly specify swift-testing as a dependency.

You'd need to do the same if your package is compiled on Linux. I am assuming this will not be necessary once Swift 6 has a proper release though.

dschaefer2 commented 1 week ago

We are not using the DEVELOPER_DIR or TOOLCHAINS environment variables.

I wonder if that's what we should be doing on macOS. That would allow us to be consistent with the command line experience.

Though as it is, if you swift build from the terminal inside VSCode you actually get different settings right now.

adam-fowler commented 1 week ago

Though as it is, if you swift build from the terminal inside VSCode you actually get different settings right now.

Yeah not ideal

Even if we used DEVELOPER_DIR we'd have this situation. We cannot affect the environment variables for the whole of VSCode, only the processes we start eg swift build etc. The terminals are setup by VSCode not the extension. There is a thing called a terminal profile, which can be used to setup a custom environment See #914 , I don't know if that affects all terminals, or add a new type of terminal.

dschaefer2 commented 1 week ago

Even if we used DEVELOPER_DIR we'd have this situation. We cannot affect the environment variables for the whole of VSCode, only the processes we start eg swift build etc. The terminals are setup by VSCode not the extension. There is a thing called a terminal profile, which can be used to setup a custom environment See #914 , I don't know if that affects all terminals, or add a new type of terminal.

Yeah, I'm not sure there's a clean answer to that other than to change the environment before you launch vscode. And really the most use of this will be in this time frame when the Xcode Beta is out and people want to try the latest Swift toolchain to pick up any fixes along the way.

My scenario is even weirder, working on swift-package-manager where I need the latest toolchain to test but with the old Xcode SDKs, but then want to use the Xcode beta for other projects :).

adam-fowler commented 1 week ago

My scenario is even weirder, working on swift-package-manager where I need the latest toolchain to test but with the old Xcode SDKs, but then want to use the Xcode beta for other projects :).

You can use the Swift Environment Variables setting to set DEVELOPER_DIR for any swift operation that is triggered by the extension

matthewbastien commented 2 days ago

My thoughts so far are that there are two scenarios here when the user selects a toolchain:

  1. An Xcode toolchain is selected in which case we should be setting DEVELOPER_DIR to the Xcode path.
  2. A public/nightly toolchain is selected which is a bit trickier. If there are multiple Xcodes installed on the system then we should ask the user which Xcode they want to select - like the Swift: Select Xcode Developer Dir... command we used to have before the toolchain selection obsoleted it.

It really boils down to the fact that we should be setting DEVELOPER_DIR if there are multiple Xcodes installed on the system. The TOOLCHAINS environment variable is also straightforward to set alongside our swift.path configuration which I can experiment with. I'm working on a PR to push up that folks can try out.

dschaefer2 commented 2 days ago

A twist in all this is that the CommandLineTools doesn't support the TOOLCHAINS env var. That makes me much less enthusiastic about relying on it.

For cross platform, I can see a scenario where the user does an xcode-select --install to get a minimal development environment and then installs the latest Swift toolchain for things like Swift Embedded. But we'll need to actually set the PATH to the toolchain to pick that up properly.