- deduplicate the logic to compute the resource folder
- install headers and module files in shared and static resource folders
- forward -static flag when calling swiftc with -print-target-info
Since libDemangling is included in the Swift standard library,
ODR violations can occur on platforms that allow statically
linking stdlib if Swift code is linked with other compiler
libraries that also transitively pull in libDemangling, and if
the stdlib version and compiler version do not match exactly
(even down to commit drift between releases). This lets the
runtime conditionally segregate its copies of the libDemangling
symbols from those in the compiler using an inline namespace
without affecting usage throughout source.
The host platform should be using `CMAKE_SYSTEM_NAME STREQUAL Darwin`.
However, we currently drive the host side of the compilation against
custom variables. This makes the migration simpler by ensuring that the
entire file uses the same pattern.
Since `is_darwin_based_sdk` is now used only in the standard library
build, sink it to the standard library build.
Also remove some ancient logic to detect and ignore requests to use LLD.
If people want to explicitly use LLD, they probably have a reason and we
shouldn't second guess them.
Windows had moved to C++14 much earlier than the rest of Swift. This
was required in order to deal with the Windows SDK headers. Now that
the project has fully moved to C++14, remove the unnecessary settings
for Windows.
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.
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 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.
