This should enable scaling when using machines with large amount of
RAM.
To better support machines with lower spec, process one binary per
dsymutil invocation (reverting #34149).
Add some (limited) facilities to gather the time taken to execute
dsymutil to better assist in tuning the parameter -- these are printed in
JSON format in the log to allow for easier scraping
```
{ "command": "dsymutil", "start": "2020-11-18T18:10:47" }
{ "command": "dsymutil", "end": "2020-11-18T18:14:45" }
```
Addresses rdar://71018443
Along with options to disable the mandatory clean using: `--skip-clean-swift-driver` and `--skip-clean-swiftpm`.
This will ensure that every invocation of build-script will, by default, clean up all build artifacts of these projects and re-build them from scratch.
This is needed for all builds because today arbitrary changes to the compiler can lead to us being unable to incrementally build components that are themselves written in Swift. This causes now-frequent failures in incremental build bots, and is a scenario that is encountered by developers. (For example see: rdar://65006593)
The proper long-term solution is to enable library evolution for these projects. Until this is done, the only safe thing to do is to always rebuild them.
Resolves rdar://65006593
This allows for child cascading presets to mixin a parent preset and then
selectively turn off these projects. store_true in contrast can not be
overwritten making cascading impossible.
The `mock.assert_called()` method was added in Python 3.6,
so fails on some of our older CI machines that use Python 3.5.
`assert(mock.called)` is precisely equivalent and works with
older versions of the Python unittest.mock library.
The experimental concurrency model will require a supporting runtime
and possibly end-user-visible library constructs. Introduce a stub of
such a library, enabled by a new `build-script` option
`--enable-experimental-concurrency`, so we have a place to put this
work.
* More Python3 lint fixes
Some of the issues addressed include:
* Don't use `l` as a variable name (confusable with `1` or `I`)
* `print` statement does not exist in Py3, use `print` function instead
* Implicit tuple deconstruction in function args is no longer supported,
use explicit splat `*` at the call site instead
* `xrange` does not exist in Py3, use `range` instead
* Better name per review feedback
- Fix extra space in build-script arg to build swift-format.
- Fix python lint errors in `swiftformat.py`.
- Remove swiftsyntax from swiftformat build preset.
This product supports building and testing swift-format, forwarding the commands to a build script inside of swift-format's repo to handle actually invoking Swift PM. There are new command line options to support the swift-format product:
`--swiftformat`: Enables building swift-format.
`--skip-test-swiftformat': Disables running tests for swift-format after building.
Installing is intentionally not implemented because swift-format isn't ready to be installed as part of the Swift toolchain.
Add build-script command-line options for building, installing, and
testing swift-driver:
* `--swift-driver` will build the Swift driver. If testing is enabled,
it will be tested as well
* `--install-swift-driver` will install the `swift-driver` and
`swift-help` executables in the toolchain.
* `--skip-test-swift-driver` will disable testing of the Swift driver
when other tests are being run.
The Swift driver depends on SwiftPM to build; it is recommended that
you use `--infer` to get the appropriate dependencies built.
Note that this option does not yet replace the existing Swift driver
executables (`swiftc`, `swift`) with the new driver, nor does it
install the SwiftDriver library for use elsewhere.
This causes build-script to use the conservative dependency information that I
committed. When one uses this option, it is assumed that one wants to also
install all built products.
Some notes:
1. I included an extra --install-all option so without --infer enabled
one can enable this sort of install everything that we want to
build behavior.
2. I added %cmake as a lit variable. I did this so I could specify in
my build-system unit tests that on Linux they should use the just
built cmake (if we built cmake due to an old cmake being on the
system). Otherwise, the build system unit tests took way too
long. These are meant to be dry-runs, so building this cmake again
is just wasteful and doesn't make sense.
3. I unified how we handle cmark, llvm, swift with the rest of the
build products by making them conditional on build_* variables, but
to preserve current behavior I made it so that they are just
enabled by default unlike things like
llbuild/swiftpm/foundation/etc. This was necessary since previously
we would just pass these flags to build-script-impl and
build-script didn't know about them. Now I taught build-script
about them so I can manipulate these skip-build-{cmark,llvm,swift}
and then just pass them down to build-script-impl if appropriate
rather than relying on build-script-impl to control if these are
built.
Once this lands, I think we are at a good enough place with
build-script until we get rid of build-script-impl in terms of high
value QoI that will imnprove productivity. Once build-script-impl is
destroyed, we can start paring back what build-script itself does.
This is just based off of the defaults that we use on the buildbots as of this
commit.
In order to not break the bots as they are, I left the internal representation
as a semicolon list of components. So this should be NFC from the perspective of
the bots since they all explicitly specify llvm-install-components if needed
(and we do not install without install-llvm anymore).
Support the usual `--enable-*san options`, but also add a
`--test-indexstore-db-santitize-all` that runs the tests once for each
sanitizer. Sanitizing just indexstore-db with a regular toolchain should
be much faster than using sanitized compilers.
To match the current value in llvm-project. This fixes runnign clang
tests under build-script without explicitly setting the version, where
there is a test passing -fclang-abi-compat=9 that was previously
failing.
rdar://60376468
Now that the autodifferentiation support is being upstreamed, add an
option to enable building the TensorFlow swift-apis package optionally.
This enables easier development cycles for the engineers working on it.
This migrates the playground support out of the build-script-impl and
into the python based build system. This makes it build more similarly
to the Swift Package Manager and SourceKit-LSP. More importantly, it
reduces the dependency on build-script-impl.
The build scripts assume Android cross-compilation using the NDK, so avoid
that configuration if building on an Android host. Fix or disable some tests,
and don't install a glibc.modulemap without a native sysroot prefix.
