This adds a new copy of LLVMSupport into the runtime. This is the final
step before changing the inline namespace for the runtime support. This
will allow us to avoid the ODR violations from the header definitions of
LLVMSupport.
LLVMSupport forked at: 22492eead218ec91d349c8c50439880fbeacf2b7
Changes made to LLVMSupport from that revision:
process.inc forward declares `_beginthreadex` due to compilation issues due to custom flag handling
API changes required that we alter the `Deallocate` routine to account
for the alignment.
This is a temporary state, meant to simplify the process. We do not use
the entire LLVMSupport library and there is no value in keeping the
entire library. Subsequent commits will prune the library to the needs
for the runtime.
The `-force-single-frontend-invocation` flag predates WMO and is now an
alias for `-whole-module-optimization`. We should use the latter and let
the former fade into history.
Remove the flag being specified in multiple locations unnecessarily.
The flags flow downwards to all the subdirectories. Use that to apply
the C/C++ flags from the root of the runtime repository.
The “ios-like” build flavor is used to build modules that do not exist on macOS for Mac Catalyst. Even though they are built for the “OSX” SDK, they need to have a “MACCATALYST”-style module triple; unfortunately, the transition to naming swiftmodules by module triple in #31170 did not handle this edge case correctly.
This commit handles that by piggybacking on a similar special case used to change the lib/swift subdirectory.
The standard library (and other Swift modules built by our CMake build system)
has been building module files with an architecture only (e.g., x86_64.swiftmodule)
rather than a proper module triple (x86_86-apple-macosx10.15,
x86_64-apple-ios13.0-simulator, etc.), unlike every other build
system. There are hacks in the compiler and other tools to cope with
this unnecessary build difference. Fix the module file names so we'll
be able to remove the hacks later.
Fixes rdar://problem/49071536.
The two invocations here both had a single parameter passed to it.
Replace it with `add_dependencies` which already actually supports
multiple dependencies specified. Sink the custom wrapper into the
usage location in `AddSwiftStdlib.cmake`.
New files were added in #30875 which did not include os(OpenBSD), so add
this.
add_swift_target_library in AddSwiftStdlib subsequently required
modification. _add_target_variant_link_flags likely needs modification as
well, but this is better suited to a separate PR.
This is a purely code motion change. It moves the functions that are
specific to `SwiftSource.cmake` into `SwiftSource.cmake`. Target
functions are moved to `stdlib/cmake/modules/AddSwiftStdlib.cmake`.
Hoist the responsibility for adding the linked libraries out of
`_add_swift_executable_single` to the invoker. This impacts only
`swift_add_target_executable`. This continues to bring the computation
of the properties nearer the site of definition.
`EXCLUDE_FROM_ALL` should be discouraged. `ALL` should build *all*
targets. If a subset of targets are desired to be built, we should
provide targets which make sense. Sink the single use of this flag
into the standard library setup. The custom cross-compilation was
the reason that the flag was plumbed all the way through. Cleaning
up the macros that have been built up is needed to migrate towards
proper cross-compilation support.
The `add_swift_target_executable` is used in a single case, where it is
already being built in a standard library only build. This removes the
unnecessary condition in the build path.
This was used for the swift-reflection-test tool. Instead of using fat
binaries, use the target binary itself. This simplifies the build logic
as well as paves the road to sub-builds for each target rather than a
monolithic build as we have today.
Originally, the swift-reflection-test was a host tool that linked
against the target libraries since it was testing the target layout.
Now that the tool has been split into a host and target component
(5ea5bb06a3) and we have target and host
libraries that we can link against appropriately, we do not need to link
against the FAT binary. Since there was exactly one use of this
functionality, switching that from fat linking to regular linking allows
us to remove this functionality entirely. Switch to regular linking and
remove the option.
This will ensure that additional target executables can not be added to the rest
of the swift project without anyone noticing since the non-stdlib parts of
Swift's cmake will not have visibility of the declaration unless they change the
cmake lookup paths.
