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.
This change makes build-script-impl use a new, shared version of swift-stress-tester’s build-script-helper.py which also supports building swift-evolve. It also adds the necessary flags and variables to build swift-evolve from build-script.
Build and install Foundation static. We now build Foundation using
CMake, which does not easily generate static and shared versions of
libraries. Create two builds to populate the toolchain
distribution.
build and install libdispatch static. We now build libdispatch using
CMake, which does not easily generate static and shared versions of
libraries. Create two builds to populate the toolchain distribution.
