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.
This doesn't make sense on Windows and from what compnerd has said it doesnt
even appear in the ninja rules file. This also moves this rule out of the main
flow of the top level CMakeLists.txt file so I can reuse it when compiling the
stdlib using a sub-cmake invocation.
The entire project is now at C++14. Windows had to adopt C++14 earlier
to support processing the Windows SDK headers. This is no longer
necessary, adopt the global settings instead.
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.
The variable was supported to be set to the triple, except it was set to
the variable itself, effectively setting the variable to nothing. This
is needed to clear the path to directory style installation for
non-Apple targets.
Out of all operating systems ever supported by Swift, only Ubuntu 14.04
had libstdc++ 4.8, and Swift has sunset support for Ubuntu 14.04 for a
while now.
Following #31125 and #31612, `-target` is not added automatically to
linker flags when that's needed (e.g. when building for Apple SDKs) --
mimic the logic used to add it for compiler flags.
Addresses rdar://63138761
If we do an external benchmark build, we will do it via the toolchain benchmark
build-script job. This will be simpler by allowing us to build against a just
built toolchain and separate us from the rest of swift's main CMakeLists.txt.
Add dependencies on the files for gyb to ensure that updates gyb are
treated as triggers to regenerate the files. This is suspected to have
caused issues for incremental builds.
This flag does not make sense here as this function is called from
`_add_host_variant_link_flags` and `_add_host_variant_c_compile_flags`.
The latter will add the flags appropriately. The former is always
invoked *after* `_add_host_variant_c_compile_flags`. This effectively
was duplicating the flags.
Rather than defaulting both of these to true, enable gold by default
only on ELFish targets, and enable LLD by default for Windows on
non-Windows hosts.
The toolchain does not actually use any catalyst flavor, which resulted
in these paths actually being dead. Cull them except for the one path
which simply computes the target triple.
This is just a cleanup of the implementation of
`add_swift_host_library`, reorganizing the flag computation and
application as well as the property setting.
This function is used at one site and is an internal function. Host
libraries are always built in a single configuration, just inline it to
avoid unnecessarily reparsing arguments.
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.
Use a newly introduced `swift_gyb_target_sources` to gyb and use the
generated sources when building. Let CMake figure out when to run the
command, let it invoke the command properly, and indicate that the
sources being added to the target are generated.
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`.
The host tools do not use ICU, only the standard library does. Remove
the special handling in the host tool path for ICU. This simplifies the
flag computation and allows the ICU handling to be sunk entirely into
the target specific paths.
Convert the out parameters for `_add_host_variant_c_compile_flags` to
use the target as an in-parameter. Doing so allows us to set the
properties on the target directly rather than providing them as out
parameters which then get set subsequently.
Convert the out parameters for `_add_host_variant_link_flags` to use the
target as an in-parameter. Doing so allows us to set the properties on
the target directly rather than providing them as out parameters which
then get set subsequently.
Perform some constant folding, constant value propagation, dead argument
elimination over the flag computation methods. This reduces the
unnecessary parameters and more clearly and succinctly describes what is
happening.
Apply constant value propagation to the host flag variant operations.
This reduces the parameters needed for the invocations and enables
further cleaning in the hopes that we can apply these per-target using
CMake instead.
Merge the single use `_add_swift_host_executable_single` into the
singular site. The host tools are built in a single variant. This
avoids the custom logic for adding multiple variants. Folding this
away will allow further simplifications in order to move towards a
standard CMake build.
Remove some unused parameters for this function. This simplification
will make it easier to merge `_add_swift_host_executable_single` into
`add_swift_host_executable`.
The build systems that drive Swift compilation have been using the
"simulator" environment as part of the increasingly inaccurately
named "target triple" to specify simulator targets for several
years... except our own hand-rolled build system. Identify
simulator targets and append "-simulator" to their target
triples.
Commit for CMake and build scripts to recognize OpenBSD. To keep this
commit relatively short, this just deals with the rather simple and
uncontroversial changes to the build system.
Note that OpenBSD calls "x86_64" as "amd64", Since the Swift stdlib will
be put in a subdirectory named after ARCH, to ensure the standard
library is properly found later, we use the native architecture name for
OpenBSD in the build system rather than trying to deal with the
difference the other way around.
After noticing that also in CMake 3.16 the LINKER: prefix is not
expanded correctly when used in `target_link_options`, prefer to set the
linker parameters in a more verbose way and leave a comment behind on
when this behavior was observed in case we want to change the
implementation later.
Follow up to #29636.
Addresses rdar://problem/59732421
