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.
I always forget the exact python invocation to run this test and I am sure
others do as well... so why not just write a script that always remembers it?
- 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
* swift_build_support: do not raise exception when capturing shell with optional flag
This fixes one of https://bugs.swift.org/browse/SR-2966 failed tests when testing environment trying to instantiate FreeBSD toolchain on Linux and `sysctl` is not in the PATH
* swift_build_support: fix shell test
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.
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.
A mix of "powerpc64" and "ppc64" existed, causing build failures.
Standardise on "powerpc64" and "powerpc64le", which are commonly used in
target triples, such as those generated by config.guess.
Signed-off-by: Russell Currey <ruscur@russell.cc>
- This change moves the top-level invocation driver loop into `build-script`
and uses the `-impl` script to perform each individual action. Once landed
and enabled, this will enable us to migrate the individual pieces of the
`-impl` script into Python code in an incremental fashion.
- This also introduces stub product definitions for each of the different projects
we manage.
- This works, but is disabled by default (`--no-legacy-impl`) because it
severely impacts the performance of null builds (4x slower, currently) due to
the `build-script-impl` parsing overhead. If only we had a JITing bash
implementation...
- This adds several platform/target properties used to configure the default
behavior for a build.
- This also adds an API to find a target from a name.
