Currently SwiftOnoneSupport.o waits on Swift.o to finish compiling before we start
compiling SwiftOnoneSupport.o. We don't need the .o for compilation but instead just
need Swift.swiftmodule which we were generating anyway.
This change causes .o and { .swiftmodule, .swiftdoc } to be built independently of each
other. Downstream compiles only wait on the module while downstream links wait on the .o.
Given that .apinotes are sometimes used by swiftc invocations, this also separates out
apinotes in to its own step which these other commands can both depend on.
The result of this is a 30% improvement in building the stdlib with -R and 20% with -d.
Specifically, -R drops from 3m to 2m and -d drops from 12m to just under 10m.
Fixes the Android build, and makes some adjustments for Android NDK r13.
* Fix FindICU.cmake to properly set the `SWIFT_${sdk}_ICU_UC` and
`SWIFT_${sdk}_ICU_I18N` values. These were not properly set because
"uc" and "i18n" were lowercase.
* Adapt `add_swift_library` to parse `ICU_UC` and `ICU_I18N` for
private link libraries and use the proper `SWIFT_${sdk}_ICU_*` values.
* NDK r13 removes a subdirectory from the llvm-libc++ includes path.
Adapt to this change, and add a FIXME to address this issue before it
may break again.
* Update the documentation to point to a new libicu download for NDK 13.
This reverts commit 23987b26f3.
I originally thought that I was going to need this for LTO work. Now it is just
dead code.
Even if we were to enable this though it wouldn't fix the underlying issue since
swiftc would still emit bitcode that may be incompatible with the host compiler.
So reverting this makes the most sense.
The Swift runtime can be built for Android on Linux host machines using
the instructions in `docs/Android.md`. This commit allows a static build
of the runtime to be compiled on macOS host machines as well.
This work is inspired by @compnerd's work in enabling Windows builds
from macOS hosts. It assumes host tools are already built for macOS. It
also does not support building SDK overlays yet. I intend to support these in a
future commit.
For now, the Android runtime may be built by using the following bash
script, which simply calls CMake:
```sh
set -e
set -x
HOME_DIR="/Users/bgesiak"
APPLE_DIR="${HOME_DIR}/GitHub/apple"
BUILD_DIR="${APPLE_DIR}/build/Ninja-Release"
CMARK_SRC_DIR="${APPLE_DIR}/cmark"
CMARK_BUILD_DIR="${BUILD_DIR}/cmark-macosx-x86_64"
LLVM_SRC_DIR="${APPLE_DIR}/llvm"
LLVM_BUILD_DIR="${BUILD_DIR}/llvm-macosx-x86_64"
SWIFT_BUILD_DIR="${BUILD_DIR}/swift-macosx-x86_64"
ANDROID_NDK_DIR="${HOME_DIR}/android-ndk-r12b"
LIBICU_SRC_DIR="${APPLE_DIR}/libiconv-libicu-android"
LIBICU_BUILD_DIR="${LIBICU_SRC_DIR}/armeabi-v7a"
SWIFT_ANDROID_BUILD_DIR="${APPLE_DIR}/build/SwiftAndroid"
mkdir -p "${SWIFT_ANDROID_BUILD_DIR}"
cmake \
-G "Ninja" \
\
-DCMAKE_C_COMPILER:PATH="${LLVM_BUILD_DIR}/bin/clang" \
-DCMAKE_CXX_COMPILER:PATH="${LLVM_BUILD_DIR}/bin/clang++" \
\
-DSWIFT_PATH_TO_CMARK_SOURCE:PATH="${CMARK_SRC_DIR}" \
-DSWIFT_PATH_TO_CMARK_BUILD:PATH="${CMARK_BUILD_DIR}" \
-DSWIFT_CMARK_LIBRARY_DIR:PATH="${CMARK_BUILD_DIR}/src" \
-DSWIFT_PATH_TO_LLVM_SOURCE:PATH="${LLVM_SRC_DIR}" \
-DSWIFT_PATH_TO_LLVM_BUILD:PATH="${LLVM_BUILD_DIR}" \
-DSWIFT_PATH_TO_CLANG_SOURCE:PATH="${LLVM_SRC_DIR}/tools/clang" \
-DSWIFT_PATH_TO_CLANG_BUILD:PATH="${LLVM_BUILD_DIR}" \
-DSWIFT_NATIVE_LLVM_TOOLS_PATH:STRING="${LLVM_BUILD_DIR}/bin" \
-DSWIFT_NATIVE_SWIFT_TOOLS_PATH:STRING="${SWIFT_BUILD_DIR}/bin" \
\
-DSWIFT_ANALYZE_CODE_COVERAGE:STRING=FALSE \
-DSWIFT_SERIALIZE_STDLIB_UNITTEST:BOOL=FALSE \
-DSWIFT_STDLIB_SIL_DEBUGGING:BOOL=FALSE \
-DSWIFT_CHECK_INCREMENTAL_COMPILATION:BOOL=FALSE \
-DSWIFT_STDLIB_ENABLE_RESILIENCE:BOOL=FALSE \
-DSWIFT_STDLIB_SIL_SERIALIZE_ALL:BOOL=TRUE \
-DSWIFT_BUILD_PERF_TESTSUITE:BOOL=FALSE \
-DSWIFT_BUILD_EXAMPLES:BOOL=FALSE \
-DSWIFT_INCLUDE_TESTS:BOOL=FALSE \
-DSWIFT_EMBED_BITCODE_SECTION:BOOL=FALSE \
-DSWIFT_TOOLS_ENABLE_LTO:STRING= \
-DSWIFT_AST_VERIFIER:BOOL=TRUE \
-DSWIFT_SIL_VERIFY_ALL:BOOL=FALSE \
-DSWIFT_RUNTIME_ENABLE_LEAK_CHECKER:BOOL=FALSE \
\
-DCMAKE_BUILD_TYPE:STRING=Release \
-DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE \
-DSWIFT_STDLIB_BUILD_TYPE:STRING=Release \
-DSWIFT_STDLIB_ASSERTIONS:BOOL=TRUE \
-DSWIFT_BUILD_RUNTIME_WITH_HOST_COMPILER:BOOL=TRUE \
-DSWIFT_HOST_VARIANT=macosx \
-DSWIFT_HOST_VARIANT_SDK=OSX \
-DSWIFT_HOST_VARIANT_ARCH=x86_64 \
-DSWIFT_BUILD_TOOLS:BOOL=FALSE \
-DSWIFT_INCLUDE_TOOLS:BOOL=FALSE \
-DSWIFT_BUILD_REMOTE_MIRROR:BOOL=FALSE \
-DSWIFT_BUILD_DYNAMIC_STDLIB:BOOL=FALSE \
-DSWIFT_BUILD_STATIC_STDLIB:BOOL=TRUE \
-DSWIFT_BUILD_DYNAMIC_SDK_OVERLAY:BOOL=FALSE \
-DSWIFT_BUILD_STATIC_SDK_OVERLAY:BOOL=FALSE \
-DSWIFT_EXEC:STRING="${SWIFT_BUILD_DIR}/bin/swiftc" \
\
-DSWIFT_ENABLE_GOLD_LINKER:BOOL=TRUE \
-DSWIFT_SDKS:STRING=ANDROID \
-DSWIFT_ANDROID_NDK_PATH:STRING="${ANDROID_NDK_DIR}" \
-DSWIFT_ANDROID_NDK_GCC_VERSION:STRING=4.9 \
-DSWIFT_ANDROID_SDK_PATH:STRING="${ANDROID_NDK_DIR}/platforms/android-21/arch-arm" \
-DSWIFT_ANDROID_ICU_UC:STRING="${LIBICU_BUILD_DIR}" \
-DSWIFT_ANDROID_ICU_UC_INCLUDE:STRING="${LIBICU_BUILD_DIR}/icu/source/common" \
-DSWIFT_ANDROID_ICU_I18N:STRING="${LIBICU_BUILD_DIR}" \
-DSWIFT_ANDROID_ICU_I18N_INCLUDE:STRING="${LIBICU_BUILD_DIR}/icu/source/i18n" \
\
"${APPLE_DIR}/swift"
cmake --build "${APPLE_DIR}/swift" -- -j8 swift-stdlib-android-armv7
```
This approach side steps the whole dependency issue between the lipo target and the codesign target by just combining them (if needed). This is accomplished by moving the codesign code into `_add_swift_lipo_target` and having it conditional on passing `CODESIGN` as an option.
This patch also updates `_add_swift_lipo_target` to use named arguments instead of positional ones, and provides a little bit of cleanup. There is more opportunity for larger refactoring and cleanup here by not generating a lipo target at all on non-darwin platforms.
When building on a macOS host, and when `SWIFT_INCLUDE_TESTS` is specified,
the `swiftSwiftReflectionTest` target is added to all platforms.
However, this target has a dependency upon Foundation, which is not
available on non-Apple platforms.
Use `add_swift_library`'s `TARGET_SDKS` parameter and other gating
logic to ensure the target is only added for platforms that actually
have Darwin available.
This reverts commit 10506e00c0.
There are dylibs in lib/swift/macosx/x86_64/ and lib/swift/macosx/, and
with this patch the dylibs in the latter path don't get updated when the
code changes and are stale.
I'm not sure exactly how to correct this patch so let's just try again
when it updates both sets of dylibs.
rdar://28660201
The CMake variable `APPLE` is set to true when building on a macOS
host, which means that logic to include linker flags for application
extensions, etc., will be enabled on a macOS host. That is, they will
be enabled even when cross-compiling the standard library to a
non-Apple platform, such as Android.
Instead of using `APPLE` to check the host OS, check whether the target
is an Apple platform.
When compiling the Swift standard library for Android on Linux, the
target prefixes and suffixes for static and shared libraries happen to
be the same for both platforms. When using a macOS host to compile,
however, the suffixes are different, causing build errors.
Explicitly set the prefixes and suffixes to prevent errors when
building on macOS.
Checking CMAKE_SYSTEM_NAME to append Darwin-specific flags happens to
work when cross-compiling from one Darwinian system to another -- like
using a macOS host to build the standard library for iOS. It doesn't
work, however, when cross-compiling from macOS to Android, for example.
Instead of checking the host system name, check whether the SDK target
is Darwinian.
Swift's CMake build system creates "fat" binaries for Swift libraries,
so long as the host machine used to compile the libraries is a macOS
machine. However, when a non-Darwin target, such as Android, is being
compiled on a macOS host, this doesn't work. Instead, only add lipo
targets if the *target* is Darwin.
Add a function to set library target prefixes and suffixes. When new
targets require setting these prefixes/suffixes, contributors will be
able to modify this one function. NFC.
Enable CMake policy CMP0057, which allows `if()` statements to use the `IN_LIST`
operator. In addition, simplify several `if()` statements that used the
`list(FIND ...)` operation instead.
CMake's ninja generator doesn't apply POST_BUILD steps to phony targets, instead in creates standalone CUSTOM_COMMAND actions for them. The generated CUSTOM_COMMANDS then end up running always because they don't have properly specified dependencies.
This patch changes the code sign step on the lipo commands from being POST_BUILD commands to being standalone commands with properly specified inputs and outputs. It works by appending "-unsigned" to the name of the lipo target and the lipo output on Darwin build and replacing the lipo target with a target that wraps the code sign command.
With this patch re-running ninja on an already built build directory no longer results in re-codesigning all the stdlib dylibs.
When building non-standalone and using the in-tree clang all TARGET_LIBRARIES should depend on clang. This ensures clang is built before the build tries to use it.
The main action here is to sink the creation of the installation rule for all of
the swift host tools into this API. In a latter commit, I will use this API to
create include and build rules for add_swift_host_tool.
This will remove the restriction that overlays always need to have a source
file matching the name of the framework, at the "cost" of standardizing the
"swiftFoo" convention for libraries with a module named "Foo". (Until
someone exposes the MODULE_NAME setting at the add_swift_library level.)
If this passes all tests, a follow-up commit will adjust the names of
some of the source files in stdlib/.
rdar://problem/17535693
Now that I am going to be adding an IN_SWIFT_COMPONENT argument, I need to do
this to distinguish the concepts of an LLVM_COMPONENT and a SWIFT_COMPONENT.
Currently when we build with bitcode, we use the liblto that we just built,
despite the fact that we just compiled the runtime with the host clang. Really,
we should be consistent.
In the short term to unblock LTO (which wants to use the host liblto), provide
an option to use the host liblto but leave it off so that the normal behavior is
preserved.
As an additional fix, this moves the include of SwiftXcodeSupport to the one
place where its functionality is used, AddSwift.cmake. Keeping the include in
./CMakeLists.txt makes it seem like the functionality is needed there (when it
is not).
In a subsequent commit, I am going to refactor the xcode support I have been
adding to SwiftSharedCMakeConfig into this file and have SwiftSharedCMakeConfig
import it.
Introduce two new aliasees `ALL_POSIX_PLATFORMS` and `ALL_APPLE_PLATFORMS`. The
latter expands to iOS, tvOS, watchOS, macOS and if relevant, the simulators.
The former expands to the same list as `ALL_APPLE_PLATFORMS` as well as Linux
and FreeBSD.
2633a0f3 expanded SWIFT_MODULE_DEPENDS_* to treat Linux and FreeBSD
separately. Android needs the same treatment as Linux, so expand the
Linux check to include Android as well. These changes fix an Android
build error, in which Glibc was not linked to private stdlib libraries
that relied upon it.
When the standard library is built dynamically on COFF targets, the public
interfaces must be decorated in order to generate a proper DLL which can be
confused by the dependent libraries. When the exported interface is used, it
must be indirectly addressed. This can be done manually in code or the MS
extension of `__declspec(dllimport)` may be used to indicate to the compiler
that this symbol be addressed indirectly. This permits building more pieces of
the standard library dynamically on Windows.
