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.
Restore the previous commit which somehow passed the buildbot given a
missing condition on the sub-configure for libdispatch. This makes it
more explicit as to what the desire is; the variable was being used to
serve as a proxy for whether the build is not on a Darwin target.
This flag was being used as an alias for whether or not the host is
non-Darwin. Rather than adding custom checks for this, use the explicit
check that CMake supports. This simplifies the logic and avoids the
proliferation of custom variables which can become confusing for others
who are not familiar with the custom build infrastructure.
This removes the custom `LINK_LIBS` in favour of
`target_link_libraries`. This simplifies the custom functions that we
have for adding libraries, makes it easier to query the information from
ninja and will allow us to slowly remove more of the custom logic for
building the products.
On Darwin platforms, libdispatch and libBlocksRuntime are re-exported from
libSystem (via LC_REEXPORT_DYLIB). Other platforms do not have libdispatch and
libBlocksRuntime in their C runtime, so we need to explicitly link against them.
Now that we are building BlocksRuntime with hidden visibility, we do not
accidentally get the symbols from libdispatch.
Currently, SourceKit's CMake functions all use DEPENDS to specify
libraries the targets will link with. This is confusing as it doesn't
behave the same way that add_swift behaves, and implies that
dependencies are created when there aren't.
* Generate libSyntax API
This patch removes the hand-rolled libSyntax API and replaces it with an
API that's entirely automatically generated. This means the API is
guaranteed to be internally stylistically and functionally consistent.
LLVM's CMake modules include a function `llvm_process_sources()`,
which (among other things) verifies that all source files in a
directory are either included in the list of source files to process,
or are included in a list `LLVM_OPTIONAL_SOURCES`.
SourceKit's CMake functions make use of this LLVM function, but do
not register any files as "optional". When attempting to configure
CMake to include SourceKit on a Linux host machine, source files
that are only included on Darwin host machines cause this function
to raise an error.
Mark Darwin-only SourceKit files as "optional" to avoid the error.
The code goes into its own sub-tree under 'tools' but tests go under 'test',
so that running 'check-swift' will also run all the SourceKit tests.
SourceKit is disabled on non-darwin platforms.
