Windows does not support fat binaries, so the target specific components should
be placed into the architecture subdirectory. Due to the cross-compilation
model that swift has, this needs to be added explicitly for now.
This improves the integration with LLVM and the unified build. The
LLVM_INSTALL_TOOLCHAIN_ONLY flag ensures that the the development libraries are
not installed. Because this option is not defined by default, the beahavioural
changes here are not triggered by default.
Due to the horrible attrocities against software of the attempt to perform
cross-compilation in the swift build system, we need to emulate the linking
behaviour for Windows with the link against the import library. The emulation
requires the custom creation of import library targets. In order to actually
get the linking semantics correct, the dependendency targets must be created
prior to use (unlike standard CMake). The reordering ensures that we get
correct linkage when building for Windows.
Perform a simple optimization to avoid a number of string comparisions for the
host system.
Normally, the C++ shared library would have link against the C++ ABI
shared library, but the Android NDK does not distribute the later, so
one need to link manually against the static C++ ABI from the NDK.
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.
The swift image registrar uses the extension `.obj` as is traditional on
Windows. Ensure that we get the extension correct when cross-compiling with the
Swift specific cross-compilation system.
The Android targetted libraries already link (manually) with the Android
NDK C++ libraries. When using Clang and lld, an extra link to libc++ is
requested, which will fail because Android names it libc++_shared.so
instead. To avoid looking for the wrong name, and since the library is
referenced manually either way, request no linking with the standard C++
libraries (but add the math library in, which is implicitly linked when
C++ is linked, and it is needed for Glibc at least).
Ensure that the use the target specific names for the fat libraries for
non-MachO targets which do not support fat libraries. This fixes the
windows build.
gold is more strict than lld about the order of the arguments, that's
why CMake offers two different properties for the linker: LINK_FLAGS and
LINK_LIBRARIES. The former _add_variant_link_flags was adding the
libraries to LINK_FLAGS, when the correct thing is to add them to
LINK_LIBRARIES.
The change adds a new output variable for _add_variant_link_flags which
will containt the linked libraries, and CMake will be able to generate
the correct command line invocation for when gold is used.
This should fix the Android CI build.
Windows does not link against the library but the import library. When
building the target specific bits, we unfortunately do not use the cmake
build infrastructure properly. This results in us trying to link
against libraries which do not exist. Redirect the link to the right
files. This allows us to build swift-reflection-test.
Remove this special case handling for building a host library as a target
library. This is the last piece needed to support cross-compiling lldb. As a
bonus, it cleans up some of the logic in our special build system.
In https://github.com/apple/swift/pull/19973 the logic that adds "-target" when
building the C parts of the Standard Library and overlays was changed to use
CMAKE_C_COMPILER_ID to only do so when the compiler ID is "Clang". However,
on Apple toolchains the compiler ID is "AppleClang", so the target was no
longer being explicitly set.
Update the logic to relax the explicit check for "Clang" to also allow
"AppleClang".
rdar://problem/45579667
When building the target libraries, we need to install the import
library as well. Unfortunately, due to the way that the swift build
system works, we do not have the ability to rely on CMake doing the
right thing and taking care of this for us. We have to manually
construct and track the import library due to the fact that we fight the
cross-compilation support. Add some logic to extract the import
libraries and install them so that uses can actually build for Windows.
Debride the function now that it is handles only the host libraries for
the tools. These are closer in spirit to the LLVM libraries and this
function can really become a trivial wrapper around llvm_add_library.
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
The Windows headers are the system (sysroot) headers. They are not
consumed by swift but the clang importer. Furthermore, they should be
treated as system headers. Correct the flags used for the invocation.
This fixes the build of the SDK overlay for Windows.
When building the swift tools with gcc, we would fail as we would try to
pass `-target` to gcc, which does not support this option. Invert the
condition and only pass the argument when building with clang.
Fix the parameter name in `_add_swift_library_single` which would
previously not pass any value for the `INSTALL_IN_COMPONENT` due to a
missed alteration when the function was refactored. Spotted by
inspection.
Use the simpler inline form of the check in most places. The two sites
that remain have multiple uses in a single function. It should be
possible to replace those as well, though it is unclear if the overhead
of inlining the check to all the places in the function will make a
measurable difference.
