On OpenBSD, man pages go in $CMAKE_INSTALL_PATH/man. This requires
changing the default to something with a parameter when installing
on this platform.
As part of this refactor some code touched as part of #31794 to better fit into the work done in #32120 -- in detail
* `_add_host_variant_c_compile_link_flags` is now invoked by both add_swift_host_library and add_swift_host_library
* `_add_host_variant_c_compile_link_flags` now sets the target in linker arguments when building against Apple SDKs
Addresses rdar://64911978
This adjusts the target specific argument handling to use the same logic
as the toolchain, and in doing so, silences the spurious warnings when
building with a MSVC toolchain.
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.
