Previously, you were to check if a build/test/install is necessary in
the builds/test/install method which is easy to miss. This gives the
check more visibility.
- 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
- 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
This works just by passing reconfigure to build-script-impl. This lets one
remove --reconfigure from presets and let the invoker of the preset decide
whether or not to to reconfigure.
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.
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.
