Turns out we need this directory to pass to the -frontend command
for creating the interop header, so refactor the whole find module
to find it on each platform.
This patch adds a workaround for a Swift issue where boolean bitfields
with getters and setters in SWIFT_UNSAFE_REFERENCE types are improperly
imported, causing an ICE.
LibCore's list of ignored header files for Swift was missing the Apple
only files on non-Apple platforms. Additionally, any generic glue code
cannot use -fobjc-arc, so we need to rely on -fblocks only.
When the detected SDK for CMAKE_OSX_SYSROOT and friends has the same
version as your current macOS system version, CMake helpfully doesn't
set CMAKE_OSX_DEPLOYMENT_TARGET. Unfortunately, in this case, swiftc
will default to macOS 10.4, which is absolutely ancient. Grab the target
triple from the -print-target-info JSON when CMAKE_OSX_DEPLOYMENT_TARGET
is not provided at configure time.
Instead of using a global setting, let's set this per-target. This
prevents conflicts when importing third-party dependencies that do
not tolerate the mode being "default".
At the same time, simplify CMakeLists magic for libraries that want to
include Swift code in the library. The Lib-less name of the library is
now always the module name for the library with any Swift additions,
extensions, etc. All vfs overlays now live in a common location to make
finding them easier from CMake functions. A new pattern is needed for
the Lib-less modules to re-export their Cxx counterparts.
In theory the clang module map should not have absolute paths for the
headers. Other Swift projects seem to use the -ivfsoverlay feature of
clang to work around this, but it seems difficult to get to work.
And modernize the cmake_parse_arguments() call at the top.
Ideally, we would pull these flags from the target we're generating
for, but the current CMake setup makes that prohibitively infeasible.
