CC: @belkadan @gwynne

One of the fun side effects of this is that you can't do the equivalent of, for example, build-script --release-debuginfo --swift-build-type=Debug.

I think we should focus on /MD{,d} first, and worry about "everything statically-linked" later. Would we need to build and distribute two copies of the standard library, then? Do we want to treat these as different architectures or architecture-environments?

(i.e. lib/swift/windows/x86_64-debug)

#24849

@belkadan - yes, this will require distribution of multiple standard libraries. I say multiple, because we will need 4 runtime libraries (/MD, /MDd, /MT, /MTd). I think that we want to treat this more like Microsoft and have suffixes instead. `swiftCore.dll` and `swiftCored.dll` which reside in the same directory.

Is that better than different directories? Seems harder, especially with autolinking. swift_static wasn't really the best idea, but it's closer to that, right?

We now can do `-libc MD` or `-libc MDd` (or for those that like verbose names: `-libc MultiThreadedDLL` or `-libc MultiThreadedDebugDLL` to match Visual Studio and CMake).

I think that its definitely easier than the `swift_static`. It avoids the complexity of changing search directories and install behaviour based on the configuration. The way that `-libc` works is that it already configures the autolinking so it just becomes this very simple thing of specifying the flag properly.

Yes, but you need to do that for the WinSDK overlay too, no?

Right, the SDK overlay would be built similarly, with the `d` suffixed variants - e.g. swiftMSVCRTd.dll. We could use the `-module-name` and `-module-link-name` options to get it behave the same - that is, the user still says `import MSVCRT` but gets the `swiftMSVCRTd.lib` import library at link time. The one complication to this would be the `swiftrt.obj` that needs the variants as well.

I'd go with the d-suffixed variants, yeah. Matching the existing Windows convention (and doing better than VS already does at it, to boot!) strikes me as the least error-prone and most "intuitive" for native Windows developers, and there isn't really a difference between the various options when it comes to developers coming from other platforms anyway (since only Windows has this particular weirdness about how runtime libraries get linked).