Dispatch, Foundation and XCTest build using CMake since a couple of
months ago, so there's no need to remove the partial results before
building anymore. This should make rebuilding a little bit faster.
https://reviews.llvm.org/D58791 renames the clang-headers target to
clang-resource-headers; the clang-headers name will be repurposed for a
different target afterward. Update Swift's build system to use the new
target name.
CMake defaults to using a special <package>_DIR for finding packages.
Prefer this to import the CMake package for LLVM/Clang/Swift rather than
custom paths.
This matches the change in upstream LLDB. I've also aligned the
invocations to improve the readability and make it clear that they're
separate commands executed after each other.
(cherry picked from commit 5b1d826e9e)
CMake defaults to using a special <package>_DIR for finding packages.
Prefer this to import the CMake package for LLVM/Clang/Swift rather than
custom paths.
The original location was only invoked when build-script invked cmake
and on top of that it did not actually make it into the cmake command
line. Since build-script is running lit manually anyway, we can just
move it over there.
Now we build libcxx if and only if --libcxx is passed, like with other
optional products. This loses the intended "build if sources are
checked out" behaviour, but behaves more predictably.
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).
Fix the check for building on macOS, fix a syntax error in the script.
This should repair the macOS build of lldb with CMake. Thanks to
@slavapestov for pointing out that this path had been broken!
- Build script now builds clang_tools_extra as part of LLVM's build.
- Build script now has a new libc++ build step to allow libc++ headers to be installed in the
resulting toolchain.
- 'clang', 'clangd', 'clang-headers' & 'compiler-rt' targets are now installed for
the package build configurations for macOS and linux.
- 'clang-resource-dir-symlink' is used in the package build configuration for macOS and linux
to avoid duplication of Clang's headers and compiler-rt archives.
rdar://24912710
Previously, Build script flag --clang-profile-instr-use is only used for building
clang and llvm. This patch extends PGO to the building of the Swift compiler.
Turns on the `--no-legacy-impl` option to build-script by default; the
old behaviour is temporarily still available as `--legacy-impl`.
This causes build-script to invoke build-script-impl for every
individual build/test/install/etc. action rather than a single global
invocation. For example, a single invocation might be for
`macosx-swift-install`. This will enable the python code in build-script
to drive the overall process and add additional steps in between actions
without the involvement of build-script-impl. It also provides a path to
refactoring the existing actions out of build-script-impl individually.
Discussed as part of https://forums.swift.org/t/rfc-building-swift-packages-in-build-script/18920
The --no-legacy-impl flag was originally disabled by default because of
concerns about the performance of null builds due to the increased
number of script invocations. There is a small optimization in this
commit to use `tr` when processing command-line options instead of
bash's builtin substitution, which eliminates most of the overhead.
After this change, a null build of llvm+swift changes from 1.6 s to
2.1 s on Linux, and from 5 s to 6 s on macOS. Non-null builds and
builds that involve more build products than just llvm+swift (e.g.
corelibs) are basically unaffected since they are not correctly
incremental to begin with.
The changes to build-script-impl in this commit are to fix the behaviour
of --no-legacy-impl, which had bitrotted since it was introduced. These
changes are to make various parts of the script not rely on variables
defined in "earlier" parts of the script, which is good hygiene in
general.
This flag '--swiftsyntax-install-prefix' could be used in the preset mode
to specify an installation dir. If we are building SwiftSyntax without building
the rest of the compiler, we'll install the SwiftSyntax modules and dylibs
with lib_InternalSwiftSyntaxParser.dylib to the given directory directly, ignoring
the conventional toolchain locations.
Previously, build-script-impl would set this to "" by default, resulting
in nothing being installed with --install-swift unless you explicitly
set --swift-install-components as well. Now we defer to cmake by
default.
On the cmake side, change the default value to exclude
* dev - uses a lot of disk space and usually not something you want to
install into a toolchain
* clang-resource-dir-symlink & clang-builtin-headers-in-clang-resource-dir -
these are mutually exclusive with clang-builtin-headers
* sourcekit inproc/xpc - these are currently mutually exclusive, so pick
the best one for the current platform.
