Support build path flag that for all vscode-swift operations

[smumriak]

Is your feature request related to a problem? Please describe.
Swift Package Manager provides ability to customize the location of "build directory" via --build-path argument. Sourcekit-LSP extension used to provide setting called sourcekit-lsp.serverArguments, which was successfully adopted by vscode-swift. There's also swift.buildArguments setting. Both of them allow setting the build directory, but it is only used by build commands and by LSP itself. Other useful features like test view, test running, launch task generation and package resolve are using hardcoded assumption of .build directory instead.

Describe the solution you'd like
Provide a dedicated extension setting that will be used as an argument for --build-path of LSP server and all swift package manager commands spawned by vscode-swift

Describe alternatives you've considered
Keeping the inability of setting custom build directory.

[adam-fowler]

There is also the alternative of including a swift.commonArguments setting which is a list of arguments applied to all swift calls.

[smumriak]

While this is viable idea for everything related to execution of swift package manager commands and sourcekit language server, this will, unfortunately, not work for next cases:

• creating launch tasks. this is not a swift command, but it requires to know the location of build artifacts in to pass the executable to lldb
• generating tests for dependencies, since the extension code needs to know location of those dependencies checkouts locations in order to crawl them. this is actually the same of any dependency-related operation that is performed by extension itself

[stevapple]

I think this is worth an option. Add to personal todos.

[smumriak]

I'm sending the PR right now :)

[stevapple]

I'm sending the PR right now :)

Go ahead:) There is a withSwiftCompileFlags() in utils that you can make use of.

[markst]

👍

Might it possible to pass the Xcode DerivedData default path?

"swift.buildPath": "~/Library/Developer/Xcode/DerivedData",

to match that of what might be passed to xcodebuild?

xcodebuild -scheme Demo -configuration Debug -sdk iphonesimulator -derivedDataPath ~/Library/Developer/Xcode/DerivedData -allowProvisioningUpdates ARCHS=arm64 

[adam-fowler]

Might it possible to pass the Xcode DerivedData default path?

I don't think that would work. Xcode has a different structure to its build data. Even if it was structured the same you would have to include the project folder inside DerivedData.

[adam-fowler]

#288 resolves this

[smumriak]

I don't think that would work. Xcode has a different structure to its build data. Even if it was structured the same you would have to include the project folder inside DerivedData.

yep, DerivedData is not the build directory for xcode projects. the build directory is inside derived data and its name is constructed from project name itself and some kind of unique identifier. we would not be able to replicate this without access to xcode source code.

the goal is to give users the power to use it as they need. you can make a change in global vscode setting to make DerivedData a default build path for all swift projects, but i would highly discourage that

[adam-fowler]

@smumriak your comment just made me think. It really doesn't make sense allowing buildPath to be configurable at the user level. Should we set its scope to machine-overridable. https://code.visualstudio.com/api/references/contribution-points#contributes.configuration. Below is a list of the scopes a configuration setting can have

scope

A configuration setting can have one of the following possible scopes:

• application - Settings that apply to all instances of VS Code and can only be configured in user settings.
• machine - Machine specific settings that can be set only in user settings or only in remote settings. For example, an installation path which shouldn't be shared across machines.
• machine-overridable - Machine specific settings that can be overridden by workspace or folder settings.
• window - Windows (instance) specific settings which can be configured in user, workspace, or remote settings.
• resource - Resource settings, which apply to files and folders, and can be configured in all settings levels, even folder settings.
• language-overridable - Resource settings that can be overridable at a language level.

Configuration scopes determine when a setting is available to the user through the Settings editor and whether the setting is applicable. If no scope is declared, the default is window.

[smumriak]

hey @adam-fowler. yea, it totally makes sense!