Because swift_swap_compiler_if_needed updates the compiler ID to
Clang, we need to account for it when deciding to add a dependency on
clang. Otherwise, the sourcekit build could fail due to the clang
executable not having been built there yet.
As of CMake 3.25, there are now global variables `LINUX=1`, `ANDROID=1`,
etc. These conflict with expressions that used these names as unquoted
strings in positions where CMake accepts 'variable|string', for example:
- `if(sdk STREQUAL LINUX)` would fail, because `LINUX` is now defined and
expands to 1, where it would previously coerce to a string.
- `if(${sdk} STREQUAL "LINUX")` would fail if `sdk=LINUX`, because the
left-hand side expands twice.
In this patch, I looked for a number of patterns to fix up, sometimes a
little defensively:
- Quoted right-hand side of `STREQUAL` where I was confident it was
intended to be a string literal.
- Removed manual variable expansion on left-hand side of `STREQUAL`,
`MATCHES` and `IN_LIST` where I was confident it was unintended.
Fixes#65028.
We need an option to pass external host clang location in case
we can't use just-built clang, e.g. when we are building for
different target architecture.
Also, this adds target options for clang-cl, enabling us to
build for arm64 on Windows@amd64.
The latest CMake on Windows doesn't add `_CRT_USE_BUILTIN_OFFSETOF`
flag after we swap the compiler to clang-cl for targets like SourceKit. Also
`_add_host_variant_c_compile_flags` doesn't do so, because compiler
identification still points to MSVC compiler.
`_CRT_USE_BUILTIN_OFFSETOF` flag is necessary for `offsetof` calls to be
accepted as an integral constant expression.
This patch adjusts compiler identification on compiler swap and also
addresses some configuration issues related to clang-cl.
Do not attempt to use a cross-compiled compiler for a foreign target. This is not guaranteed to work (e.g. building for ARM on x64). This at least surfaces the error properly.
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.
