When building with unified builds, `CMAKE_SOURCE_DIR` is not the Swift
repository. Use the locally defined `SWIFT_SOURCE_DIR` variable to
reference the root of the Swift repository. Because libswift uses
`project` in the CMakeLists, we cannot use `PROJECT_SOURCE_DIR` here.
Fixes a linux build error.
It doesn’t make sense to let add HAS_LIBSWIFT to add_swift_host_library(). This was added to work around a linker bug (d22b348adb). Instead do the workaround in libSwiftScan/CMakeLists.txt.
Don't build the swiftCore module files in the bootstrapping phases. Instead use the module files in the SDK.
This reduces the build time overhead from 3min -> 30seconds.
* fix a typo which prevented linking the right bootstrapping libs
* build swiftDarwin for bootstrapping
* disable COW checks if built with bootstrapping-with-hostlibs
The latest Long Term Support NDK finally removed binutils, including the bfd/gold
linkers and libgcc. This simplifies our Android support, including making lld the
default linker for Android. Disable three reflection tests that now fail, likely
related to issues with swift-reflection-dump and switching to lld.
Also, add the libatomic dependency for Android armv7, just as on linux.
Adding build modes for libswift: off, hosttools, bootstrapping, bootstrapping-with-hostlibs
The two bootstrapping modes are new. For details see libswift/README.md
Using `support` llvm component ends up adding `-Xlinker /path/to/lib/libLLVMDemangle.a`
to `LINK_FLAGS` but `libLLVMDemangle.a` is not added as an input to the linking ninja statement.
As a workaround, in order to setup precise inputs for the ninja link statement, include `demangle` component
whenever `support` is mentioned.
This ensures that we pick up libraries from the toolchain before picking up
libraries from the SDK we are using. Normally it would not matter the order that
we add these -L files since the contents of the SDK and toolchain are
disjoint. Once we begin performing stage2 swift builds though, we no longer have
this property since we pass in the stage1's installed libraries as the SDK
directory and we have not split the two sets of libraries yet. The end result is
that if we have the -L in the previous order, we will pick up just built
compatibility libraries before we pick up the actual compatibility libraries
from the actual toolchain we are using to compile. This results in compilation
breakage.
The mangler fuzzer and reflection fuzzer build was broken, both by a problem in
the CMake scripts and also because of changes that have happened in other parts
of the code.
After talking with compnerd, because we're passing this directly to the
swift driver, we shouldn't have to do anything weird with the flags and
it should "just work". I'm frustrated enough with Windows that I'm just
going to go with that and go to bed. If I broke something, I'm sorry. I
tried as far as my sanity would allow.
This patch fixes the part of the build system where we aren't passing
the sanitizer flags to swift, so the linker isn't linking against the
sanitizer libraries.
* add the (still empty) libswift package
* add build support for libswift in CMake
* add libswift to swift-frontend and sil-opt
The build can be controlled with the LIBSWIFT_BUILD_MODE cmake variable: by default it’s “DISABLE”, which means that libswift is not built. If it’s “HOSTTOOLS”, libswift is built with a pre-installed toolchain on the host system.
This is just cruft that remained from the time when swift's host/target used the
same cmake code. Host tools do not statically link against just built artifacts.
There are three things going on here (note all on Darwin):
1. If one compiles a swift static library and links the static library into a
cxx executable, the cxx executable will need the -L flags to find the
appropriate libraries in the SDK/toolchain.
2. I fixed an rpath issue where due to old code I didn't understand/propagated
forward, we were setting the rpath to be the -L directory in the appropriate
SDK. After reasoning about this a little bit I realized that this was code
that was actually intended to be used for target libraries (for which the
given rpath would be correct). On the host side though on Darwin, we want to
use the rpath for the standard stabilized stdlib on the system.
3. I added Build System Unittests to ensure that this keeps on working. I also
added test cases that I should have added before. I just had never thought
about how to test this and I realized this method would work and would
prevent regressions while I am waiting for a new swiftc with driver fixes to
land.
Before a8ae9525aa, we could not do this since we
would fail to link since we didn't pass to clang the path to the toolchain dir
when the compatibility libraries live.
I already did this for executables. The reason why we must do this is that right
now there are bugs in cmake's swift support that makes it so that one can not
use swiftc to link targets with mixed c/c++/swift content even if the swift
content is indirectly added via linking. To work around this we must also ensure
that all libraries with mixed c/c++/swift objects link using clang. As an
additional side-effect of this, we must pass to the clang linker -L flags that
swiftc would normally provide for the linker. The two cases where I needed to do
this were:
1. -L path for the compatibility libraries. This path points into the toolchain
where these live. This is important since otherwise we will fail to link given
the minimum deployment target that swift (both host/stdlib) target today (10.9).
2. -L path to the SDK. This path points to the SDKs lib/swift/${HOST_PLATFORM}
for swiftCore and friends.
That being said, we still want people to be able to link pure swift libraries
using swiftc, so we introduce an option called PURE_SWIFT to add_host_library
that preserves this and is used to also set
IGNORE_LLVM_UPDATE_COMPILE_FLAGS (which arguably should have been called
PURE_SWIFT).
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.
