The --dump-config option prints a recursive JSON dump of the BuildScriptInvocation object’s properties, which gives access to essentially all of the knowledge build-script has about the build before it starts performing it. This makes the output more flexible and extensible without severely convoluting the implementation, but doesn’t really give us a stable representation of that data.
Adds an --expand-invocation argument, which is now the preferred name for this feature. Leaves the original name in place in case someone is using it in a script.
If passed, build-script doesn’t build anything; it just prints the full path to the directory the invocation would have built its products in. This is intended to allow you to build tools which take build-script options like --debug and --xcode and use them to determine the build directory you’re currently using.
The previous commit moved the note containing the output to stderr. This change prints it on stdout again, but now with no human-consumption prefix so it can be directly executed by tools.
Build a separate compiler-rt instance for running the tests. It is built
and tested against an installed toolchain instead of the llvm-build-dir.
Install everything we need to run tests (CMake modules, FileCheck, etc.)
into the toolchain directory.
Add synthetic target 'all' for llvm-install-components. Also we must set
LLVM_INSTALL_UTILS=ON, so the utilities required by tests (e.g.,
FileCheck) are included in the install target.
ProductBuilder allows us to tackle the different way than the different
products need to be build. The builders follow a very simple interface,
but inside them the details are hidden.
Previously the Ninja product was both a Product and ProductBuilder. The
methods that did the build have moved into ProductBuilder to match the
future ProductBuilders.
This is a better name for the internal interface. The outside option is still
--toolchain-benchmarks to distinguish it from the normal --benchmarks which is
part of swift's cmake.
execute_one_impl_action is checking for the validity of its arguments, when it
can be enforced by the structure by using smaller focused methods that trickle
down into a common function.
This structure will eventually allow different builders to participate in a
script invocation. Each builder will be told to build/test/install, and they
will not have to deal with anything else. The content of these smaller methods
will end up as part of the builder that uses build-script-impl.
The calculation of the plaforms to build/test were only used by HostSpeficicConfiguration, but were done in BuildScriptInvocation, and to make things work, the full BuildScriptInvocation object was passed down onto HostSpecificConfiguration. The changes in this commit move the code into HostSpecificConfiguration, and only pass `args` into it to let itself calculate the platforms to build/test.
This will allow in the future that HostSpecificConfiguration can to be removed from the main script file, can be tested and can be used by several parts of the build script process. During a transition period, it will be useful for the builder that delegates to build-script-impl, but in the end, it might only be useful for the Swift builder.
As proposed in #23822, the do_* methods should only be using the * parts. Because all building should have the same names, this commit removes the prefix from all the method instances.
Move the calculations of platforms_to_skip_build, platforms_to_skip_test, platforms_archs_to_skip_test, and platforms_to_skip_test_host to their own independent functions. Each function deal with one of them and they are pure functions, which should improve readability a little.
This reverts commit b9e17a7656.
Unfortunately, this caused conflicts on the Apple internal CI.
Reverting this for now. This can be split up into smaller patches to
make it easier to merge.
Now one can on Darwin/Linux build the benchmarks via swiftpm from build-script by passing in:
```
build-script $NORMAL_ARGS --install-swift --install-swiftpm --install-llbuild --toolchain-benchmarks --swiftpm --llbuild
```
This is done using the infrastructure that BenL added for sourcekit-lsp.
This will allow using HostSpecificConfiguration from other parts that
are not the main script in the future.
Additionally, a lot of code that was part of BuildScriptInvocation has
been moved into HostSpeficiaConfiguration because nobody else needed it,
and HostSpecificConfiguration was highly coupled with the Invocation
object (through one of its arguments). This should make the
Configuration object a better citizen in other scenarios.
Passing an empty string to this option either as
"--extra-swift-args=''" or "--extra-swift-args ''" would cause
build-script-impl to fail to parse some arbitrary number of other
options.
This is impossible to debug from the build log because all of the
build-script-impl options still show up in the log. So, cutting and
pasting the build-script-impl command actually works.
Turns out this is why build-script build and install stages never
worked for me, beyond running cmake.
The manipulation of host-test and skip-android-host was a little
different than the equivalent skip-ios-host and similar variables. These
changes make them closer and allows executing only the compiler tests,
but skip the test that need an Android device to run.
- Disables the upload command of the tests if the subset is the
non-executable tests. The non-executable test do not need to be
uploaded, and in the case of Android, a device doesn't need to be
connected, so trying to connect to one will fail.
- Fix a problem where the swift_interpreter feature was removed without
first checking if it was really added.
- Only enable the host tests (the compiler tests) in the Android CI
preset (there's no device attached to that server, but currently only
the Linux tests were being executed, which doesn't make a lot of
sense).
- Move the decision about which platform support device/host tests into
the platform themselves, which allows Android to have device/host
tests. Also modify a little bit the logic around enabling/disabling
the test suite to allow running only the host tests of a platform.
- Fix the suffix name for the target of non-executable tests in a couple
of places.
Now we build libcxx if and only if --libcxx is passed, like with other
optional products. This loses the intended "build if sources are
checked out" behaviour, but behaves more predictably.
Add support to build-script to build and test the indexstore-db and
sourcekit-lsp projects. A future change will add support for installing
these products and putting them in the toolchain. To build the new
products, add the `--sourcekit-lsp` or `--indexstore-db` options to a
`build-script` invocation.
We add the notion of a Product that is not part of build-script-impl and
build these products after the install phase of build-script-impl. These
products are built using the installed toolchain - either using the
default location within the build subdirectory, or the user-specified
`--install-dest`. This is somewhat rigid setup, since it requires the
toolchain used to build to be the same as the final installed toolchain
(if any), but it makes for a simpler change to the existing builds while
still making progress towards a toolchain-based build model.
*Note*: currently, if you are not using a preset you will need to
manually specify all of the dependencies (on macOS this is
swiftpm and llbuild, on other platforms you additionally need
libdispatch, icu, foundation, and xctest), and the install flags for the
same projects (`--install-llbuild --install-swiftpm ...`). This is not
particularly user-friendly, but it matches the current behaviour of the
other targets, and there is not yet any infrastructure in build-script
to describe these dependencies.
Turns on the `--no-legacy-impl` option to build-script by default; the
old behaviour is temporarily still available as `--legacy-impl`.
This causes build-script to invoke build-script-impl for every
individual build/test/install/etc. action rather than a single global
invocation. For example, a single invocation might be for
`macosx-swift-install`. This will enable the python code in build-script
to drive the overall process and add additional steps in between actions
without the involvement of build-script-impl. It also provides a path to
refactoring the existing actions out of build-script-impl individually.
Discussed as part of https://forums.swift.org/t/rfc-building-swift-packages-in-build-script/18920
The --no-legacy-impl flag was originally disabled by default because of
concerns about the performance of null builds due to the increased
number of script invocations. There is a small optimization in this
commit to use `tr` when processing command-line options instead of
bash's builtin substitution, which eliminates most of the overhead.
After this change, a null build of llvm+swift changes from 1.6 s to
2.1 s on Linux, and from 5 s to 6 s on macOS. Non-null builds and
builds that involve more build products than just llvm+swift (e.g.
corelibs) are basically unaffected since they are not correctly
incremental to begin with.
The changes to build-script-impl in this commit are to fix the behaviour
of --no-legacy-impl, which had bitrotted since it was introduced. These
changes are to make various parts of the script not rely on variables
defined in "earlier" parts of the script, which is good hygiene in
general.
This flag '--swiftsyntax-install-prefix' could be used in the preset mode
to specify an installation dir. If we are building SwiftSyntax without building
the rest of the compiler, we'll install the SwiftSyntax modules and dylibs
with lib_InternalSwiftSyntaxParser.dylib to the given directory directly, ignoring
the conventional toolchain locations.
This change makes build-script-impl use a new, shared version of swift-stress-tester’s build-script-helper.py which also supports building swift-evolve. It also adds the necessary flags and variables to build swift-evolve from build-script.
