This is specifically important for host libraries that include swift
content. llvm_update_compile_flags currently doesn't conditionalize the flags it
adds since it needs to be updated like I updated Swift's cmake in
558c9d4086.
In the short amount of time that I am dealing with upstream to patch those
flags, this patch will unblock eeckstein and let him continue with his libswift
work.
In certain cases our executables are going to have a mix of cxx,swift. There are
current issues when linking cxx,swift code with swiftc itself, so this lets us
avoid that problem.
I am in the process now of preparing the tree for the addition of Swift code in
the optimizer as a normal source of source file. The goal is to make it so that
one can just include a random swift library anywhere in the swift project host
build and the cmake will use the swift compiler from the host
toolchain/compile-link the code just as if it was a normal host side thing (1).
In order to do this though, we need to deal with the legacy of our cmake
creating compile flags without constraining the flags to only being used if
cmake is compiling c/c++ code. To fix this, I just inserted generator
expressions into the host side swift build's cmake that uses generator
expressions to perform such conditionalization. The result is that the parts of
a target that are c/c++ will get these flags, but these flags will not propagate
to any Swift files that we add.
(1) With time this implies that we will need to be able to bootstrap the swift
compiler. We are not crossing that bridge now since the only places that we are
going to use this today is in the SILOptimizer optimier passes. These can always
be disabled while cross compiling, meaning that we can make progress here
without having the bootstrapping completely ironed out.
Otherwise we set it on all targets/languages in a subdirectory (I forgot if it
propagates up). Regardless, this type of viral stuff is something we want to
move away from since it creates a code that is a "forall" piece of code rather
than a piece of code that only effects a single target.
I also conditionalized the actual definitions being added on the compiled file's
language being C,CXX,OBJC,OBJCXX since as we add Swift sources to the host side
of the compiler, we will not want these flags to propagate to Swift sources.
Since the NDK removes the platforms/ and sysroot/ directories in the latest NDK
22, switch to the unified sysroot in toolchains/llvm/ and take advantage of a
bunch of simplification that's now possible.
There's no reason to use -m${platform}-version-min as of clang-11/Xcode 11. Clang is now smart enough to parse -target and provide Apple's ld with the appropriate -platform_version argument string.
Credit for the cmake fix here goes to Saleem Abdulrasool.
The substantive fix is embarrassing; I didn't pay close attention
to the intrinsic's argument order and just assumed that the first
argument for the replacement value was the low half (the part
you'd find at index 0 if it were an array), but in fact it's the
high half (the part you'd find at index 1).
I also change the code to be much more reinterpret_casty, which
isolates the type-punning mostly "within" the intrinsic, and
which seems to match how other code uses it.
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
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.
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.
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
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.
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.
