If IFS remains set, it may cause compilation errors due to unanticipated
replacement of characters in some parameters.
Addresses rdar://problem/57927748
In the majority of cases, we can derive the value of SWIFT_HOST_VARIANT,
SWIFT_HOST_VARIANT_SDK, and SWIFT_HOST_VARIANT_ARCH from the value of `host`
itself. The goal of this patch is to make those derivations and avoid lots of
manual setting of values. Because we verify that we have a valid host before
doing this, we can be sure that errors should be caught before we try to
deconstruct the host into platform and architecture values.
For situations where you can't derive those values from the host, we leave
existing behavior -- that is, we handle them in a switch statement.
By verifying that the host is supported before doing any operations, we can
assume that the host value is properly formed, meaning we can simplify the logic
to set values based on the host. Follow-up commits will do exactly that.
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.
* [build] prefer picking up sqlite3 from Darwin SDK for llbuild
When building llbuild on Darwin platforms, ensure that we prefer the SQLite from the SDK
instead of picking one found elsewhere (e.g. in /usr/include )
Also consider only the SQLite dylib shipped with the OS.
Addresses rdar://problem/57300418
Why am I doing this?
Because we have now switched to the monorepo, we no longer need to have logic to
detect whether or not a project is present. Any project under the llvm project
is guaranteed to be available if you're building llvm.
I hope this is the first change of many that can clean up some of the logic in
build-script-impl. Some simplifications and cleanups that I think can be made
include:
- Adding the option to build swift as a part of the llvm build. (Or even making
this the default behavior)
- Taking advantage of `LLVM_ENABLE_PROJECTS` to simplify some of the logic to
set up clang, clang-tools-extra, and other projects.
- Builds libFoundation.a, libFoundationNetworking.a and
libFoundationXML.a and installs them in usr/lib/swift_static/linux
- Note this does NOT make -static-stdlib work for Foundation at this time.
Teach build-script to build lldb's `install-distribution` target when
installation is required, and make the lipo action invoke lipo when
cross-compiling.
Incidentally this fixes a bash warning about `continue` being invalid
outside of a loop.
Check whether there are any cross compile hosts by looking at the
CROSS_COMPILE_HOSTS array, not at ALL_HOSTS, as these can be different
due to --skip-local-build.
Rename LLDB_ALLOW_STATIC_BINDINGS to LLDB_USE_STATIC_BINDINGS and make
LLDB use the static bindings unconditionally when it's set. The current
variable is opaque because it allows LLDB to use the static bindings,
but only if SWIG is not found. If an incompatible version of swig is
found, it reports a fatal error. This serves no purpose other than to
confuse the user.
The corresponding LLDB patch simplifies things and makes the variable do
what you expect. When enabled, LLDB uses the static bindings. When
disabled, we try to generate them with SWIG.
This patch modifies the build scripts to pass the new variable.
Setup the CMake invocation for the migration to CMake 3.15. This will
allow us to simplify the s-p-m bootstrap and the llbuild build itself
(see apple/llbuild#587).
