Array tests take longer on the simulator and constantly time out.
The proper solution would be to split the Arrays.swift.gyb into
multiple, though.
<rdar://problem/30250367>
This enables one to dump the various passpipelines in a yaml format. Other
pretty print formats can be added in the future as well if desired. Its intended
usage is to provide a source of pass pipeline information for external python
bug-reducing tools. By integrating this as a compiler-tool, we are guaranteed to
never have to update any of these tools in the face of passpipeline changes.
...if the Python 'psutil' module is installed.
We have no individual tests that take longer than 20 minutes, and
having lit provide the timeout will be a better experience than having
a buildbot kill the whole job.
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.
The incremental mode orders test by the last time modified, instead of
by the path, it also touches the files for failed tests, in order for
them to be prioritized on the next run. Using this mode as the default
improves both the CI and local development experience: CI builds
triggered by the commit, that includes changes to the tests, will run
those tests first; locally, it makes a lot of sense to run previously
failed tests first to make sure they've been fixed.
In LLVM, the convention is that *_INCLUDE_* means that cmake will generate
targets but says nothing about whether or not something will be built by default
or not. This means that as far as cmake is concerned, those targets do not
exist.
On the other hand, *_BUILD_* determines whether or not a class of things is a
dependency of the "all" target. Of course this implies that *_BUILD_* implies
that *_INCLUDE_* must be set to TRUE.
Currently SWIFT_BUILD_TOOLS is implemented like a *_INCLUDE_* option, so change
its name to SWIFT_INCLUDE_TOOLS.
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.
We do not use any variables in our lit.site.cfg.in files that are not already
set at this point in the configuration. So all calling this function does is
create some variables that are not used and then calls configure.
This commit just removes the call to the function and calls configure directly.
This simplifies the code (we are not calling into llvm) and reduces exposure to
llvm internals changing.
rdar://26154980
So that we can easily invoke manual testing:
cmake --build ${SWIFT_BUILD_DIR} -- upload-stdlib-{variant}
python ${LLVM_SOURCE_DIR}/utils/lit/lit.py -sv ${TEST_PATH}
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.
Removing an abstraction boundary also allowed me to fix a bug where we
could not run long tests in optimized mode, which prevented us from
being able to mark executable tests as long.
A nested loop was adding arguments specific to the current iteration to
a variable, where the arguments persisted into the next iteration.
The issue only affected the only_validation-only_non_executable
configuration, here's why. The test subsets were configured in the
following order: primary, validation, all, only_validation, only_long.
The first three were not adding new arguments. 'all' was adding
arguments that were affecting 'only_validation'. Then 'only_long' was
adding an argument of its own that was overriding the argument from
'all'.
* The behavior of `build-script -t` is unchanged.
* `build-script -T` continues to run primary and validation test suite,
but without the long tests.
* `build-script --long-test` runs just the long tests.
* `build-script -T --long-test` runs all tests.
This adds an Android target for the stdlib. It is also the first
example of cross-compiling outside of Darwin.
Mailing list discussions:
1. https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151207/000171.html
2. https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151214/000492.html
The Android variant of Swift may be built using the following `build-script`
invocation:
```
$ utils/build-script \
-R \ # Build in ReleaseAssert mode.
--android \ # Build for Android.
--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/
```
Android builds have the following dependencies, as can be seen in
the build script invocation:
1. An Android NDK of version 21 or greater, available to download
here: http://developer.android.com/ndk/downloads/index.html.
2. A libicu compatible with android-armv7.
This tool links against target-specific stdlib/public/Reflection,
so make sure to only include it as a dependency when stdlib is getting
built. Otherwise, separate overlay builds can fail because ninja can't
find the target-specific dependencies.
rdar://problem/25556475
swift-reflection-test isn't a standalone host-side tool anymore, but a
target executable, so the dependency needs to include the variant suffix
(e.g. -macosx-x86_64) in the name.
