Support custom environment

[stevapple]

Is your feature request related to a problem? Please describe.

Swift and SwiftPM has several features that are controlled by environment variables. Allowing user to specify the custom environment they want with Swift is necessary to test out some opt-in features.

Describe the solution you'd like

Add a new configuration the controls additional environment variables to pass to Swift and SwiftPM.

Either separate (Swift/SwiftPM) or unified control is acceptable IMO. For full control over the environment, we also need a way to unset existing environment variable.

Describe alternatives you've considered

This is purely addictive and the only workaround today is to modify the system's environment: rather risky and expensive.

[smumriak]

This would be great feature to add. Right now vs code does not allow setting "global" environment variables to be used by all extensions and expects each extension to provide its own setting for that if needed

[adam-fowler]

PR's so far merged #256 and #258

[adam-fowler]

@stevapple can you give me some examples of environment variables that affect swift build and swift package manager operations? Is this something you seeing being added to swiftRuntimeEnv?

[stevapple]

can you give me some examples of environment variables that affect swift build and swift package manager operations?

Most of them control lookup path(s) for tools and libraries, and others are likely to enable/disable some features. I'm not quite sure if there's documentation, but you can always search Swift Driver and SwiftPM source codes for that. The only one we're taking care of now is SDKROOT.

Is this something you seeing being added to swiftRuntimeEnv?

No. They should be of something like swiftCompilerEnv or swiftBuildEnv. Tasks like running tests and debugging products do not need them.

[adam-fowler]

So a more generalised version of your SDKROOT PR would cover this.

[adam-fowler]

@stevapple can we close this with the merge of #305

[adam-fowler]

Ha I added a waiting on input tag over a year ago. I'm guessing we can close this one.
I'm going to add a replacement issue to add support for cross compilation destination bundles