The newest VS2019 release updates CMake to 3.20, which picks up
`llvm-mt` as a preferred manifest tool. However, we do not build
`llvm-mt` with libxml2 support currently, which prevents the use of the
just built manifest tool for building libdispatch. Explicitly opt into
using the MSVC manifest-tool.
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.
gtest, gtest_main LINK_LIBRARIES dependencies changed by that removed scripts to absolute library file path. as a result losing necessary include path dirs.
This will make sure that compiler developers are using the new driver when they build the compiler locally and use it.
- Adds a new build-script product category: before_build_script_impl for products we wish to build before the impl products.
- Adds a new EarlySwiftDriver product to that category, which gets built with the host toolchain.
- Adds an escape hatch: --skip-early-swift-driver
- Adjusts the swift CMake configuration with an additional step: swift_create_early_driver_symlinks which (if one was built) creates symlinks in the swift build bin directory to the EarlySwiftDriver swift-driver and swift-help executables.
- Adds a new test subset : only_early_swiftdriver, which will get built into a corresponding CMake test target: check-swift-only_early_swiftdriver-* which runs a small subset of driver-related tests against the Early SwiftDriver.
- This subset is run always when the compiler itself is tested (--test is specified)
- With an escape disable-switch: --skip-test-early-swift-driver
- All tests outside of only_early_swiftdriver are forced to run using the legacy C++ driver (to ensure it gets tested, still).
NOTE: SwiftDriver product (no 'Early') is still the main product used to build the driver for toolchain installation into and for executing the product's own tests. This change does not affect that.
Commit the platform definition and build script work necessary to
cross-compile for arm64_32.
arm64_32 is a variant of AARCH64 that supports an ILP32 architecture.
add target include directories on AddSwiftUnittests.cmake module.
currently generated Xcode project doesn't include googletest headers after https://reviews.llvm.org/D86616
For cross-compiling Android one can simply provide
CMAKE_ANDROID_ARCH_ABI and the right CMAKE_SYSTEM_PROCESSOR will be
chosen by CMake. Since the SDK arch names are not the expected ones by the Android NDK,
it is better not to use them. The change should keep sending the
CMAKE_SYSTEM_PROCESSOR for SDKs that are not ANDROID, while skipping it
for the ANDROID SDKs.
* [Concurrency] Fix Android C libdispatch build
We need to pass CMAKE_ANDROID_NDK and CMAKE_ANDROID_ARCH_ABI to the
build.
* Set proper ANDROID_ARCH_ABI
* Add -DCMAKE_ANDROID_API to C libdispatch build
* Fix compiler config for Android
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.
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.
