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.
As a first step to allowing the build script to build *only*
static library versions of the stdlib, change `add_swift_library`
such that callers must pass in `SHARED`, `STATIC`, or `OBJECT_LIBRARY`.
Ideally, only these flags would be used to determine whether to
build shared, static, or object libraries, but that is not currently
the case -- `add_swift_library` also checks whether the library
`IS_STDLIB` before performing certain additional actions. This will be
cleaned up in a future commit.
This commit makes the swift build scripts use the clang that we build as part of
the build process in order to build the Swift runtime, and not the host
compiler. This change is necessary for using new clang features immediately after they are introduced.
One example for such feature is new function calling conventions, or new c-level attributes.
We want to have the option of building the standard library without
-sil-serialize-all.
For now, the build crashes in the SIL verifier due to various issues;
upcoming patches will address these.
This is part of the larger goal of building the stdlib with
-enable-resilience.
Part of https://bugs.swift.org/browse/SR-267.
This brings down StdlibUnittest build time to 90 seconds with either
a DebugAssert or a ReleaseAssert compiler.
The new library, StdlibCollectionTests, is only built when running
validation tests.
