Before this patch, we assumed that if LLVM_INSTALL_COMPONENTS was non-empty that
we wanted to install llvm. This is different than /every other/ product in
build-script-impl where INSTALL_$PRODUCT controls if an install is attempted. If
a components sort of thing is required, we force it to only be a configuration
of an option that is a no-op if INSTALL_$PRODUCT is set to true.
I went through build-presets and looked at every place we had an install
statement and added install-llvm when appropriate. This was generally when we
did an install-swift. The one special case is with the tsan_libdsipatch
test. That being said, if I was too aggressive with where I put these
install-llvm, no harm will result since in those cases LLVM_INSTALL_COMPONENTS
had to be empty previously anyways (since otherwise we would have attempted an
install).
If we do an external benchmark build, we will do it via the toolchain benchmark
build-script job. This will be simpler by allowing us to build against a just
built toolchain and separate us from the rest of swift's main CMakeLists.txt.
This will let us use lld to link the stdlib. This will allow us to
avoid problems due to old compilers being used on certain older distributions
that we support.
If anyone wants to not build lld, they can just pass to build-script-impl
--skip-build-lld
This augments #31023 to make sure CMake invokes the compiler checks
correctly -- this is needed to avoid errors in certain
configurations.
Addresses rdar://62339814
Commit for CMake and build scripts to recognize OpenBSD. To keep this
commit relatively short, this just deals with the rather simple and
uncontroversial changes to the build system.
Note that OpenBSD calls "x86_64" as "amd64", Since the Swift stdlib will
be put in a subdirectory named after ARCH, to ensure the standard
library is properly found later, we use the native architecture name for
OpenBSD in the build system rather than trying to deal with the
difference the other way around.
This migrates the playground support out of the build-script-impl and
into the python based build system. This makes it build more similarly
to the Swift Package Manager and SourceKit-LSP. More importantly, it
reduces the dependency on build-script-impl.
The build scripts assume Android cross-compilation using the NDK, so avoid
that configuration if building on an Android host. Fix or disable some tests,
and don't install a glibc.modulemap without a native sysroot prefix.
The static variants should use the same flags as the dynamic variants.
We missed the name conversion in the variable computation causing the
static and dynamic builds to diverge.
This option configures the build directories without building any
targets. Splitting configuration from build allows for the decoupling
of build products. This decoupling is essential for the enlightened
way of developing Swift where the build-script is never actually used
to build anything, and build products can be independently
configured. When fully supported, this avoids many unnecessary
full/clean rebuilds and enables debugging by mixing-and-matching
configurations and rebuilding only select products after a change.
Sadly, the option has degraded, and a recent commit rendered it fully broken:
commit 34848e6026
Author: Alex Langford <apl@fb.com>
Date: Wed Jan 22 19:27:44 2020
[build] Unify logic to skip building projects in build-script-impl
The breaking commit was itself a reasonable cleanup. The underlying
problem was the original --skip-build was implemented using hacks that
conflated configuration with build.
This fix reinstates a reasonable situation:
--skip-build has no effect on configuration, as documented. It merely
skips building the targets. This is how it must behave to work as
intended.
--skip-build-{product} and its inverse --build-{product} controls
which products will be configured. These options are in heavy use
throughout the scripts, so changing the name (e.g. to --skip-config)
would be disruptive and of questionable benefit.
None of this changes the fact that any required build logic that
people have dumped into build-script-impl still effectively breaks the
enlightened way of building Swift, particularly when building
toolchain components.
This hoists the shared check to the beginning of the product
installation phase. This can be done as a shared phase option. In
theory it should be possible to hoist this further to a single check at
the beginning of the phase.
Rather than individually list the options, generate the options which
ensures that options are more uniform and makes it easier to alter them
globally.
