These flags have done nothing for awhile, as 26 of 31 have already been moved to
build-script. Only the flags related to haiku, maccatalyst, and external-benchmarks
are unrecognized by either build script after this removal.
Clang's driver started linking with libclang_rt.<os>sim.a when building for simulator.
Swift's build need to adapt to this clang change, by ensuring that the libclang_rt.<os>sim.a libraries are created during the build
clang and compiler-rt are rev-locked and should match. Currently, we build clang (and use it to bootstrap the rest) but don't build compiler-rt. We should.
This doesn't completely achieve that: this only makes us build compiler-rt for the local host.
This used to be pretty much impossible, but, since then, compiler-rt cmake support was rewritten.
We should build it for the other hosts as well, but that's trickier, because we'd need to make the cross-compiled compiler-rt build use a separate just-built clang (from the local host). We do that for the other projects, but compiler-rt is special (because it's cmake'd as a runtime part of clang/llvm).
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.
