Adjust the install path computation to support installation of ARM64 on
AMD64. This enables the isolation of the runtimes on all architectures
for Windows to allow building the isolated runtime distribution.
When we invoke the script block it could throw an exception so we should
wrap it in a try finally block to ensure that we can restore the old
environment variables, otherwise you can end up back in a shell that has
an incorrect set of variables set.
This is most noticable if an exception is thrown when entering the vs
dev shell since without resetting the old vars you will have invalid
Visual Studio env variables set meaning you need to manually reset your
shell environment.
EnableCaching should only configure cmake to allow for sccache usage, it
should not configure sccache itself in any way. Those configuration
options should be deferred into the environment variables that sccache
will look for when it starts up.
When setting up sccache we can choose between local disk caching or
remote caching via an S3-ish blob storage engine. To allow for backward
compatibility for anyone that might be using the existing option for
disk caching we leave it place and instead provide a new remote caching
option.
This option assumes you've read the sccache documentation for setting up
the correct environment variables for telling sccache where to find the
bucket and how to authenticate to it.
This creates a helper for building the SDK for a given OS/Architecture.
The building of the SDK should be uniform and this ensures that we can
maintain that uniformity.
This also highlights any structural changes that are being adjusted
manually. The desire is to bring this to zero by gaining control over
the install rules.
Enable the Concurrency runtime for the experimental runtime builds on
Windows. This is required to enable the use of the static runtime to
bootstrap the early swift-driver.
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.
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.
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.
