Rather than build multiple copies of LLVMSupport (4x!) build it one and
merge it into the various targets. This would ideally not be needed to
be named explicitly everywhere, but that requires using `add_library`
rather than `add_swift_target_library`.
Remove the flag being specified in multiple locations unnecessarily.
The flags flow downwards to all the subdirectories. Use that to apply
the C/C++ flags from the root of the runtime repository.
Static builds of the standard library and the SDK overlay are
unsupported post ABI stability. Disallow building of the standard
library and SDK overlay statically for Darwin platforms.
Because we do a custom cross-compilation, we are tracking the *build*
dependencies when building libraries for the *host*. That is to say, if
you are building for Linux on Darwin, we track Darwin's libc++ as a
dependency for the Linux swiftCore.
CMake supports the notion of installation components. Right now we have some
custom code for supporting swift components. I think that for installation
purposes, it would be nice to use the CMake component system.
This should be a non-functional change. We should still only be generating
install rules for targets and files in components we want to install, and we
still use the install ninja target to install everything.
Include a missing CMake module in a couple of locations that we were
using the function. Simplify a condition to use `MATCHES` rather than
two `STREQUAL`.
This adds a new copy-legacy-layouts-${platform}-${arch} target for each
platform and architecture that the standard library is built for.
If the platform and architecture has a corresponding layout file in
stdlib/public/legacy_layouts/${platform}/layouts-${arch}.yaml, the
target copies this file to the build directory; otherwise, it does
nothing.
When building Swift code, the subroutines in SwiftSource.cmake add a
dependency on this target from each Swift code target.
Finally, we ensure that the YAML files are copied into the toolchain
package when building a toolchain.
This is a cleaner, more principled way of adding "compiler launcher" support and
ensures that cmake understands that distcc is not the "actual" compiler.
This ensures that when we compile SwiftRemoteMirrors for the host, we do not try
to compile using distcc without needing to reset CMAKE_{C,CXX}_COMPILER_ARG1
(which is unset when compiling things in the stdlib).
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.
If one thinks about it, swift's build has two sections: a runtime or target
section (i.e. ./stdlib) and a host section (everything
else). swift-reflection-test is an abberation from that pattern since it is
built for target platforms but is in the section of host tools.
In this commit, I move it into ./stdlib. Beyond being a bitter location
conceptually this will additionally allow me to avoid a dependency cycle in
between the compiler and the stdlib build.
After this, there is only one more target in the compiler code: swift-lang. From
talking with Xi Ge, we can move that into its own separate project as a
package. Once that is done, I will not have any more cycles.
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.
Replace the duplicated logic for defining the targets for the standard
library variants with a call to a function that creates the targets.
This allows us to easily add variants of the standard library without
having to track all the sites for the name.
- Re-enable the use of folders with the USE_FOLDER setting. This got
lost a while ago when we stopped including LLVM's top-level
CMakeLists.txt.
- Put a bunch of new targets into folders.
Should not affect the built product and definitely shouldn't affect
anyone not building with Xcode (or MSVC, I guess).
We can finally get rid of -sil-serialize-all when building the standard library! This option will be completely eliminated in the future commits.
Instead of serializing just everything as we did before, we now serialize only functions annotated with @_inlineable. This way we can selectively control what needs to be available to the clients. This is an important step towards building a resilient standard library.
While this is a huge change for the serialization of the stdlib, it should be virtually invisible to the clients. For example, there are no noticeable performance regressions on any of the benchmarks.
When moving to the swift-4.0-branch of LLVM, we started using the
LLVM_DISABLE_ABI_BREAKING_CHECKS_ENFORCING cmake option to turn off those
checks. This was necessary for the stdlib build, where it uses some LLVM
headers without linking libSupport.a, but the cmake option forced us to
disable the checks across the board. It also caused a lot of churn for
people who needed to remove their cmake caches when switching to the new
version of LLVM. This change switches to use a preprocessor macro to
disable the checks only in the context of the stdlib build. It requires
LLVM r295090. rdar://problem/30098953
for sib/sibgen files for libraries without building them by default.
This will let engineers just cd into the build directory and type:
ninja swift-stdlib-sib
ninja swift-stdlib-sibgen
To generate sib and sibgen files respectively.
There are still some dependency issues in between the sib targets, so to get
this to work well, I would suggest doing a full build and then using these
targets.
My recent change to enable SWIFT_BUILD_RUNTIME_WITH_HOST_COMPILER by default
exposed this problem with ASan. There are some places, e.g., the
swift-reflection-dump tool, where we link together Swift runtime code with
other code built by the host compiler. If we try to use the sanitizers
with both compilers mixed together, this can cause link failures.
To get the same coverage, we probably need to sanitize the runtime
separately. rdar://problem/29567862
This splits the `--build-swift-stdlib` and `--build-swift-sdk-overlay`
arguments into `dynamic` and `static` variants, which makes the
following build command possible:
```
utils/build-script -- \
--build-swift-dynamic-stdlib=0 --build-swift-dynamic-sdk-overlay=0 \
--build-swift-static-stdlib=1 --build-swift-static-sdk-overlay=0
```
This command produces *only* static libraries for the stdlib, and no
SDK overlay libraries at all. Many other finely-grained build options
are now possible.
