This should repair the Windows build after #29451. The quoting
behaviour was incorrect and was constructing an invalid compiler
invocation. Solve the issue by using `target_include_directories`
instead. However, since this needs the target, hoist the flag
computation to the local sites. This replicates more logic because of
the custom build trying to replicate the CMake build logic in CMake.
When using the monorepo, it seems that even if Swift is built
standalone, we would see the target as imported and attempt to use the
generator expression, which would not resolve.
This is needed as SwiftSyntaxParser also needs to be built with clang as
it uses blocks unconditionally. However, building with cl provides much
better diagnostics and debugging as well as a significantly faster
build (~15-20% faster) as well as a faster compiler.
The initial configure & generate of a build on Windows should have
the necessary VCVARS set in the environment. After that, we should be
incrementally building with those same vars to avoid conflicts between
Windows SDKs.
Cache these vars so that the same Windows SDKs are consistently used
in future incremental builds.
Adjust the build to work with the VS2017 layout while maintaining the
compatibility with VS2015. The library location changed which results in the
link failing due to not finding system libraries.
`-ivfsoverlay` is no longer passed through to the driver with
`clang-cl`. Explicitly mark it as a clang option to ensure that the
option is handled properly. This repairs the build on Windows.
In order to substitute the path into the VFS overlay, we need to escape
the paths. Instead, opt on the CMake behaviour of
`get_filename_component` providing the canonicalised path with forward
slashes rather than backslashes. This allows the overlay to be used on
Windows as well as Linux.
The Windows SDK provides headers which have incorrect cases. The
incorrect cases are in the SDK headers as well. On case sensitive file
systems this causes build issues due to the incorrect name. Use the
clang VFS overlay to avoid the need for providing copies to the expected
cases. This improves the cross-compilation on Linux to Windows.
Rather than use the `INCLUDE` and `LIB` environment variables to build
the Windows code, use the `UniversalCRTSdkDir`, `UCRTVersion`, and
`VCToolsInstallDir` variables. Using these we can compute the right set
of include directories and library search paths for the various
architectures. This will enable us to build multiple variants of the
Windows stdlib at the same time.
Additionally, rather than relying on the magic environment variables to
be processed by the driver, pass them explicitly to the driver through
the build system. This also is needed to allow parallel builds of
various architecture variants of the stdlib on Windows.
