Fixing up SDK behavior

[stevapple]

• swift-package usually doesn't require SDK flag;
• XCTest path should be derived from destination's SDK;
• Remove SDK flags on non-SwiftPM calls.

[stevapple]

cc @adam-fowler

[adam-fowler]

Is there any harm in including the --sdk command line parameter even when it isn't needed. What's to say another package command requires the sdk.

[stevapple]

I would suggest to add them explicitly (since they're part of SwiftPM release). Adding unnecessary SDK flags has no effect I guess, but it will make the command line long and confusing (especially when the destination flags accumulate).

[stevapple]

@adam-fowler Ping again for this and #294

[adam-fowler]

A couple comments, otherwise it looks fine

One thing I don't get, you seem to be prepping the code to debug with a custom SDK (ie looking for xctest.dll in custom SDK), but consider running a swift script with the same custom SDK as something undesirable.

Secondly has this been tested with a custom SDK, plus does the test explorer still work (with/without a custom SDK) after these changes, similar changes broke the test explorer before.

[stevapple]

One thing I don't get, you seem to be prepping the code to debug with a custom SDK (ie looking for xctest.dll in custom SDK), but consider running a swift script with the same custom SDK as something undesirable.

In most cases, cross-compiled binaries cannot run on the host. swift test and swift run will assume by user's intent that the binary can run under the environment, so we're just following its rule here.

(BTW, XCTest is not actually in the Windows SDK. We're just regarding SDKROOT as an anchor (starting point) for the searching. All these are following the current SwiftPM implementation.)

If something is known to be run on the host (Swift package manifest, SwiftPM plugin, Swift scripts...), it should stick to use host SDK, and overriding should take SDKROOT instead of the flag. #294 clarifies the destination configuration set to be package-only.

[stevapple]

Secondly has this been tested with a custom SDK, plus does the test explorer still work (with/without a custom SDK) after these changes, similar changes broke the test explorer before.

At least everything works perfectly on macOS. On Windows I haven't got a real secondary SDK yet, and custom SDKROOT should be more useful there.

[adam-fowler]

Currently we have two points where the decision on sdk flags being added. The setSDKFlags parameter in execSwift and in withSwiftSDKFlags. Do we need both?

EDIT: Ignore this I see you have removed the setSDKFlags parameter

[adam-fowler]

We're good