Now that CMAKE_HOST_SYSTEM_NAME and CMAKE_SYSTEM_NAME are set by default to
Android in the Termux app, make the needed tweaks. Some tests were adapted
to work natively on Android too, adds sys/cdefs.h to the Bionic modulemap,
and includes the start of native Android platform support in the build-script.
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.
Add `--enable-experimental-differentiable-programming` build-script flag.
The build-script flag enables/disables standard library additions
related to differentiable programming. This will allow official Swift
releases to disable these additions.
The build-script flag is on by default to ensure testing of
differentiable programming standard library additions. An additional
driver flag must be enabled to use differentiable programming features:
https://github.com/apple/swift/pull/27446
- 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
- 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.
