- For Linux only, if the checked out CMake repository is a newer version
than the installed CMake version or CMake is not installed, build and
use CMake from source.
- This does not affect macOS build or set any minimum required CMake
version in CMakeLists.txt
- Forward several environment variables to the test environment because
Windows uses them to inform the processes about things like the number
of processors and the architecture.
- Normalize some literal Unix paths to be the same as the results in
Windows, that will have forward slashes and the drive letter.
- Skip some test that use build-script-impl and tests that check for
files being executable (everything is executable in Windows).
- Don't use the owner and group arguments for tar on Windows.
- Hide the stderr output of which. In Windows it prints the full PATH in
case of failures, which is disrupting.
- Quote many paths in Windows in the output of build-script results.
- Provide a version of mock-distcc that can be executed in Windows. The
raw Python script cannot.
- Change the expected results for clang/clang++ to the right values in
Windows (clang-cl in both cases).
This will allow using `HostSpecificConfiguration` from other parts that
are not the main script in the future. This is interesting because the
information is mostly useful when building Swift. The rest of products
are not really interested in the results of these calculations.
Includes a suite of tests that check the implementation correctly
calculates the right targets to build under diverse circumstances.
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.
CMakeOptions was briefly used in the cmake module, but mostly unused in
the rest of the modules, however, several products were dealing with
what eventually will end as CMake options, but not using the already
existing code, and duplicating it.
The changes tries to unify all usage around CMakeOptions which avoids
code duplication. Additionally, it provides some more API surface in
CMakeOptions to make it more useful.
- The initializer can be passed a list of tuples or another CMakeOptions
to copy into the newly created options.
- Boolean Python values are treated automatically as boolean CMake
options and transformed into `TRUE` and `FALSE` automatically.
- Provides `extend`, which will add all the tuples from a list or all
the options from another `CMakeOptions` into the receiving
`CMakeOptions`.
- Provides `__contains__`, which makes checking for existing options a
little easier (however, being `CMakeOptions` basically a list, the
checking has to include also the value, which is not that helpful).
- Modify LLVM and Swift products to use `CMakeOptions`. It makes the
boolean values clearer and avoid a lot of repetitive string
formatting.
- Modify the tests to make them pass and provide new test for newly
introduced features.
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.
This will let me:
1. Add -Osize support easily.
2. Put all of the binaries in the same directory so that Benchmark_Driver can
work with them via the -tools argument.
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.
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.
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.
I have been meaning to do this change for a minute, but kept on putting it off.
This describes what is actually happening and is a better name for the option.
This is a cleaner, more principled way of adding "compiler launcher" support and
ensures that cmake understands that distcc is not the "actual" compiler.
This ensures that when we compile SwiftRemoteMirrors for the host, we do not try
to compile using distcc without needing to reset CMAKE_{C,CXX}_COMPILER_ARG1
(which is unset when compiling things in the stdlib).
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.
Support for Android aarch64 in many parts of the build-script. Most of
the changes are reuse variables/parameters that already existed for
Android ARMv7. There is also a new parameter to specify the ICU
data library, which is used by #19503.
With this one can build either armv7 or aarch64, since building both
at the same time requires more changes like #19432 (and probably
more work to support two set of paths).
Prior to this, the swift build didn’t understand what i686 is, or what to do about building it. This unblocks building, but will still run into build breaks.
