- <rdar://problem/27791475>
SwiftPM can now be built in release mode because all the outstanding
issues preventing that has been resolved. The major issues were:
* Building (and running) unit tests with @testable import in
* release. (swiftpm PR #758)
* Linker errors when building unit tests with wmo on linux. (SR-3034)
There is no reason not to do this (and it is really cheap) and I want to make
some scripts use it with various clang tooling techniques like clang-tidy to
improve code quality. This will ensure that by default people can just use these
scripts without knowing about how things are working under the hood.
- Add --libicu option to compile icu from source. This allows the
configuration to be controlled so that it is enabled for shared
and static building and the static files dont require the use of
the dynamic loader
- Add --install-libicu option to install the shared libraries into
$prefix/lib/swift and the static ones into $prefix/lib/swift_static.
This avoids interference with system installed versions
- Dont use find_package if building ICU from source
The benchmark bot uses this functionality today to run the benchmarks. By
default build-script only uses 3 samples for each test. Given the noise on our
systems, this is definitely not sufficient for any sort of robust numbers.
Using this patch, I am going to change the benchmarking bot to take the minimum
of 20 samples as we do for our internal benchmarking. This should help make the
benchmark bot give better data. This will have as a cost cause the bot to take
more time. The testing time issue can be solved down the line by changing to a
protocol where we first do tests with a small number of samples (< 5). Then any
benchmark with a delta > 5% is rerun with 20 samples or perhaps until a
statistical criterion is satisfied. But until that is implemented, this at least
makes the bot useful.
There are other things that need to be changed on the benchmarking bot as well,
namely that it should build on a separate machine from which it is running the
benchmarks on. The benchmarking machine should be quiet and not have any work
being done on it. But that is also for another time.
The three included Python scripts work together to generate a sqlite3
database containing mappings of all covered Swift source code regions to
the specific tests that cover them.
Additionally, build-script support is included for utilizing the
coverage database to prioritize tests covering changes in the Swift
repository.
These are computed by build-script and passed directly by build-script-impl into
cmake for the relevant target. We can now start to migrate per product cmake
options from build-script-impl into build-script.
Rather than having the cmake generator be decided by 3 different options that
can be potentially all set (which makes no sense), this should really just be an
option called cmake_generator that would default to ninja and would have choices
of xcode, eclipse, etc.
Communicate build variant selection to libdispatch build process
using the --with-build-variant argument to libdispatch's configure
script added in libdispatch pull request #110.
This enables you to know what tests actually ran instead of just the number of
tests that ran. This helps identify:
1. Tests that are not running, but /should/ be running.
2. Tests that are XFAILED or DISABLED but should not be.
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.
When the "--android-deploy-device-path" option was first added,
build products would only be deployed to a connected Android device
if the option was specified. Now, we use `command_upload_stdlib`
to upload every time the Android tests are being run.
As a result, running the test suite for Android without specifying
a deploy path leads to a subtle error, in which the
`command_upload_stdlib` CMake command fails. End users may find this
difficult to debug.
Add a default argument to the deployment path, and check for a valid
path before executing the CMake command.
- This fixes a regression introduced in
a4537e8a0f, where we used to accept a list of
concatenated deployment targets as a single argument.
- <rdar://problem/26928189> build-script fails to split deployment targets
before iterating over them
