Including all the system header dependencies and `stat`ing them all the time introduces significant performance overhead for normal compilation, and other features like code-completion, without being worth it in practice.
Users may install a different version of SDK from the one found in the
originally downloaded toolchain. Thus, we may need to create a new directory structure
instead of using the original one in the toolchain, especially if the SDK under use has a
different version number.
rdar://67951012
When clients specify an output directory without SDK version, the script will change
the input so we emit all prebuilt module caches into SDK-versioned directories without
modifying the client side.
rdar://67951012
`sys.exit` takes an integral value in the range of `0-127`. Python 3 is
much more stringent about this and will convert the value if it is out
of the range to 1. On Windows, explicitly use `ExitProcess` to ensure
that we get the correct value on the exit code which matters to `not`.
The standard library (and other Swift modules built by our CMake build system)
has been building module files with an architecture only (e.g., x86_64.swiftmodule)
rather than a proper module triple (x86_86-apple-macosx10.15,
x86_64-apple-ios13.0-simulator, etc.), unlike every other build
system. There are hacks in the compiler and other tools to cope with
this unnecessary build difference. Fix the module file names so we'll
be able to remove the hacks later.
Fixes rdar://problem/49071536.
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.
...by crawling it and looking for module interfaces. This is the tool
Apple is using for the "prebuilt-modules" directory in the toolchain
in Xcode.app, which avoids even a first-use cost for importing modules
from Apple SDKs as long as the SDKs haven't changed. We've been
landing changes to support this model on the compiler side, so the
tool to generate the "prebuilt" compiled modules belongs in the
compiler repo too. (In theory this could be used with open-source
toolchains as well, or for alternate SDKs.)
