The ninja builder took a host argument that was unused by the function.
The ninja build failed to pass this argument, resulting in
an execution failure. Removing the argument.
The timing data collection is now homed under `Invoke-BuildStep`.
`Build-SPMProject` is an implementation detail of the build step and is
timed at a higher level.
Split up the test routines from the build routines. This is motivated by
the desire to simplify (remove logic flow) and to help get more accurate
timing data.
Split up the test routines from the build routines. This is motivated by
the desire to simplify (remove logic flow) and to help get more accurate
timing data.
Split up the test routines from the build routines. This is motivated by
the desire to simplify (remove logic flow) and to help get more accurate
timing data.
Split up the test routines from the build routines. This is motivated by
the desire to simplify (remove logic flow) and to help get more accurate
timing data.
Instead of using `--build-ninja` to decide to build ninja, build it
automatically if a sufficiently new enough version is not available.
Also record the build time taken to build the local Ninja so that we can
see how much time we would save by stashing a pre-built Ninja in CI.
This should improve CI times because building in debug configuration instead of release configuration is significantly faster. Since we don’t install the build of swift-(corelibs-)foundation using SwiftPM into the toolchain, this doesn’t have any performance impact on users of the toolchain.
Ninja builds its tests by default.
We don't run the Ninja test suite, we aren't doing development on Ninja,
and we are using a release tag that has been verified to work. There
isn't much point in building the tests if we're not going to use them.
Disabling building the Ninja tests. If it is desirable to build them,
one can set `BUILD_TESTING` to `YES` and re-run their build.
This adjusts the install location for the testing frameworks to be
versioned with the product version. These are somewhat closely tied to
the compiler, and it makes sense to tie them to the product version.
Adopt the `$Arch` parameter uniformly. If something is built for the
host we can use `$HostArch` explicitly (which identifies the
environment that the toolchain will run on). `$BuildArch` gives us an
explicit architecture when building for the machine where the toolchain
is being built. For the target libraries, we simply pass in the
appropriate `$Arch` value.
We cross-compile the Swift runtime libs for the Android SDKs in the Windows toolchain. This patch adds a build step that runs non-executable tests for them.
This patch switches the Ninja build from using the configure.py script
to building with the just-built CMake.
The configure.py in Ninja 1.11.1 still uses Python 2.7, importing the
`pipes` module. The pipes module was deprecated in Python 3.11 and
removed in 3.13, so folks using newer versions of Python are running
into issues with this.
The CMake build doesn't have this issue and is also perfectly valid, so
we can switch to that.
This patch updates the CMake-building mechanism to avoid
re-bootstrapping CMake if we already bootstrapped one that is new
enough.
I've made it so that all paths through the function return the path to a
CMake so we can use the result of the function as the cmake path without
having to check.
The function will choose one of the following ways of getting CMake in
order of preference:
- One we already built
- The system CMake
- Bootstrapping one from scratch
It prefers one we built over checking the system CMake because, if we
have already built a CMake previously, it's a good indication that
there either was no system CMake installed, or it wasn't new enough. We
shouldn't waste time checking it again if a previous run detected that
it wasn't good enough.
The system CMake is preferable to building one from scratch if we don't
need to though, so we determine if the system CMake is sufficient.
Finally, if one that we built either doesn't exist, or isn't new enough,
and the system either doesn't have a CMake, or a new enough CMake, build
one. It is built into the location that we are checking for caching, so
the next time we run build-script, it should hit the first case and
choose the already-built CMake instead of building it again.
Include the CMake bootstrap time in the build-script build times.
We're including everything else. Would be good to determine how much
time we can save by caching a new enough pre-built CMake in the builder
images.
Importing the log_time_in_scope exposes a cyclic dependency cycle
between the `swift_build_support` and `build_swift` python modules in
such a way that the tests fail due to re-importing parts of build_swift:
```
ImportError: Failed to import test module: tests.build_swift.test_migration
Traceback (most recent call last):
File "/usr/lib/python3.8/unittest/loader.py", line 436, in _find_test_path
module = self._get_module_from_name(name)
File "/usr/lib/python3.8/unittest/loader.py", line 377, in _get_module_from_name
__import__(name)
File "/home/build-user/swift/utils/build_swift/tests/build_swift/test_migration.py", line 14, in <module>
from build_swift import migration
File "/home/build-user/swift/utils/build_swift/build_swift/migration.py", line 18, in <module>
from swift_build_support.swift_build_support.targets import \
File "/home/build-user/swift/utils/swift_build_support/swift_build_support/targets.py", line 15, in <module>
from . import cmake
File "/home/build-user/swift/utils/swift_build_support/swift_build_support/cmake.py", line 26, in <module>
from swift_build_support.swift_build_support.utils import log_time_in_scope
File "/home/build-user/swift/utils/swift_build_support/swift_build_support/utils.py", line 20, in <module>
from build_swift.build_swift.constants import SWIFT_BUILD_ROOT
ModuleNotFoundError: No module named 'build_swift.build_swift'
```
I've put the import of log_time_in_scope into the function definition
to ensure that build_swift has been fully loaded by the time we need
log_time_in_scope, ensuring that there is order between the two pieces.
Python caches the imported module, so if we accidentally re-import the
log_time_in_scope, nothing actually changes.
This re-orders the instantiation of the BuildScriptInvocation object so
that it comes before the creation of the CMake path. This ensures that
BuildScriptInvocation() does not delete the build log after logging the
CMake bootstrap time. This is fine because the toolchain and arguments
are reference types, so updating the CMake path in both of those will be
reflected in the copy taken in the BuildScriptInvocation() object.
