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.
- This is consistent with the `subprocess` API, which this module is otherwise
closely related to, so I think this makes more sense than taking a list of
key-value pairs.
Under certain obscure circumstances (incomplete SDKs), xcodebuild can
successfully work with the SDK and print its version number, but will
still exit with a non-zero code. This change works around the issue by
ignoring the exit code.
