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.
There are a couple of things going on in this patch. Lets consider first the
crosscompiling case.
In the cross compiling case, we were already setting LLVM_TOOLS_BINARY_DIR to
the binary dir of the just compiled LLVM (not the native LLVM/clang). This is
exactly what using LLVMConfig.cmake from that just compiled LLVM will set
LLVM_TOOLS_BINARY_DIR.
In the non-cross compiling case, we originally grabbed LLVM_TOOLS_BINARY_DIR
from llvm-config and then used that value to set the NATIVE llvm/clang paths.
rdar://26154980
Previously in order to support cross-compiling, we were setting these variables
in build-script. Now that we are using LLVMConfig.cmake, passing in these values
are no longer necessary. As an added benefit, Swift when not cross compiling,
does not need to set these variables anyways.
rdar://26154980
At some point in the future, we may consider using LTO on the runtime/standard
library, but right now is not that time. We are just trying to use LTO to
improve the compile time performance of the compiler itself.
rdar://24717107
*NOTE* We are still passing this variable into LLVM. Just not into Swift anymore.
I originally passed in the variable -DLLVM_ENABLE_LTO=YES to Swift's cmake to
ensure that the Swift unittests were compiled with lto. That was the wrong
fix.
The reason why is that if -DLLVM_ENABLE_LTO is set to YES then HandleLLVMOptions
in llvm will append -flto to both CMAKE_C_FLAGS and CMAKE_CXX_FLAGS implying
that -flto can not be disabled selectively. This ability to disable flto
selectively is something that we need in order to lto host libraries, but not
lto target libraries.
Thus in this commit, we no longer pass in -DLLVM_ENABLE_LTO=YES to swift's cmake
invocation. Instead we apply the lto flag to the unittest target ourselves in
add_swift_unittest.
rdar://24717107
This adds support for running tests for the stdlib built
for Android, both on the host machine and on an Android device.
The Android variant of Swift may be built and tested using
the following `build-script` invocation:
```
$ utils/build-script \
-R \ # Build in ReleaseAssert mode.
-T \ # Run all tests.
--android \ # Build for Android.
--android-deploy-device-path /data/local/tmp \ # Temporary directory on the device where Android tests are run.
--android-ndk ~/android-ndk-r10e \ # Path to an Android NDK.
--android-ndk-version 21 \
--android-icu-uc ~/libicu-android/armeabi-v7a/libicuuc.so \
--android-icu-uc-include ~/libicu-android/armeabi-v7a/icu/source/common \
--android-icu-i18n ~/libicu-android/armeabi-v7a/libicui18n.so \
--android-icu-i18n-include ~/libicu-android/armeabi-v7a/icu/source/i18n/
```
See docs/Testing.rst for more details.
- Introduces a new `HostSpecificConfiguration` which holds the computed
information for each host we need to use.
- This relies on the functionality to pass host-specific variables to the
script via environment variables.
- The computation itself has been cleaned up a tiny bit (mostly via using
the factored out platform/target properties), but is otherwise a straight
port of the logic from `build-script-impl`.
- This commit does not yet remove that code from `build-script-impl`; instead
it validates that the two implementations are computing the same result.
This is useful right now for testing the validity of the port.
- This isn't yet used, but we need an easy way for `build-script` to
pass host-specific variables down to `build-script-impl`.
- I don't think it is worth complicating the main argument parsing
logic with a syntax for passing associative arrays on the command
line, so this just passes them via environment variables.
- Part of SR-237.
Use the clang that is part of the toolchain being built
when building libdispatch to ensure getting the appropriate
version of clang.
Also pass through SWIFTC_BIN to the configure command to
prepare for a cleanup of the libdispatch side of the build process.
The reason to do this is the same reason that we already pass in
-DLLVM_ENABLE_LTO=YES to swift, to ensure that parts of our codebase that use
the llvm build machinery (e.g. the unittests) do not use too many linker jobs
given the memory constraints of a given machine.
rdar://24717107
- This adds a new argument `--only-execute <name>` which can be used by
`build-script` to invoke the `build-script-impl` to perform each different
action, while moving the high-level operation loop into the `build-script`
itself. This should make incremental refactoring of the individual actions
into `build-script` easier.
- This is part of SR-237.
- It turns out that just this function by itself has a significant impact on
the runtime of the `build-script-impl` when it is being invoked many times by
the `build-script` (as I intend to do as part of SR-237).
- The current behavior of mapping via `tr` was very slow when called over and
over for each option. This matters for SR-237 where I would like
`build-script` to take over the top-level build process control loop, which
involves executing `build-script-impl` multiple times.
- This patch optimizes the lookup in two ways:
1. It does the setting to variable conversion in a single pass, for all
options at once.
2. It builds a cache of the setting to variable name conversion (as an
exploded associate array), and uses that when doing variable assignment.
- This patch speeds up `build-script-impl --dry-run` by 2x on one test case.
If -n or --dry-run is specified in command line arguments, print the commands
that would be executed to stdout, but do not execute them.
Supported in build-script and build-toolchain.
utils/build-script -n -Rt
utils/build-script -n --preset=buildbot_incremental,tools=RA,stdlib=RA
utils/build-toolchain -n local.swift
- Use consistent terminology for target platforms, disambiguate uses of
'deployment_target' in to 'host' and 'stdlib_targets'
- Changed parameters to build script:
- install-prefix no longer has to include toolchain-prefix on OSX
- swift-sdks has been replaced by stdlib-deployment-targets
- built-stdlib-deployment-targets lets you restrict which of the
stdlib-deployment targets are built
- Calculate stdlib_targets per host, to facilitate future cross-compiling
- Only use executables from LOCAL_HOST
- Only execute testable targets of the LOCAL_HOST
- Remove some cases of switching on 'uname' to facilitate future
cross-compiling
- This should fix possible issues with the test outputs being in a shared
directory on CI machines running concurrent builds.
- https://bugs.swift.org/browse/SR-1628
