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.
_OBJECT_FORMAT was added recentlyish for all the SDKs. Use that property rather
than enumerating all the ELFish targets. This ensures that the code path is
correct if another ELFish target is ported to.
Add an option which the user can specify to switch to the lld linker. Although
this linker is still nascent, it is interesting to permit linking with this. It
is also an alternative to the BFD linker for COFF targets. It will allow for a
cross-compilation story for Windows on non-Windows targets.
This allows us to cross-compile the standard library to foreign targets on a
single host. The ICU dependencies can be specified on the command line on a
per-target basis. If one is not specified, we fall back to the default search
path and use that for the other targets.
Special thanks to Dimitri Gribenko for the various hints in getting this wired
up.
This splits the `--build-swift-stdlib` and `--build-swift-sdk-overlay`
arguments into `dynamic` and `static` variants, which makes the
following build command possible:
```
utils/build-script -- \
--build-swift-dynamic-stdlib=0 --build-swift-dynamic-sdk-overlay=0 \
--build-swift-static-stdlib=1 --build-swift-static-sdk-overlay=0
```
This command produces *only* static libraries for the stdlib, and no
SDK overlay libraries at all. Many other finely-grained build options
are now possible.
The Android NDK r12 release appends a ".x" to the libgcc directory;
it is now:
```
android-ndk-r12/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.9.x
```
Update the linker path for the Android build to accomodate this change.
gold only supports ELF. This adds two new helper functions
(is_windows_based_sdk and is_elfish_sdk) to ensure that we dont try to use gold
on non-ELF targets. This comes up when trying to setup cross-compilation for
the standard library for Windows.
The ELF check is implemented as the negation of Darwin (which uses MachO) and
Windows (which uses COFF). The reason for this is that there are additional
targets which also use ELF. Rather than enumerating the larger set, enumerate
the smaller set (windows) and use the negation.
Create a helper function to determine if we are targeting a Darwin SDK or not.
The repetition is error-prone and verbose. Simplify by adding a checking
function. NFC.
Use the SWIFTLIB_SINGLE_SDK variable rather than the CMAKE_BUILD_SYSTEM variable
to determine the target type. This allows us to use the logic for adding
libraries for foreign OSes on a build host. This is needed to pave the road to
cross-crompiling the standard library for different targets.
The use of `-isysroot` is a Darwin specific behaviour. It is used to switch to
a platform SDK, however, other targets use the `--sysroot` flag. Windows uses a
custom mechanism which is a set of system header paths.
As a first step to allowing the build script to build *only*
static library versions of the stdlib, change `add_swift_library`
such that callers must pass in `SHARED`, `STATIC`, or `OBJECT_LIBRARY`.
Ideally, only these flags would be used to determine whether to
build shared, static, or object libraries, but that is not currently
the case -- `add_swift_library` also checks whether the library
`IS_STDLIB` before performing certain additional actions. This will be
cleaned up in a future commit.
HOST_LIBRARY is supposed to mean "no matter what the defaults say, also build
this library for the host". FORCE_BUILD_FOR_HOST_SDK is a less confusing name.
At some point in the future, we may consider using LTO on the runtime/standard
library, but right now is not that time. We are just trying to use LTO to
improve the compile time performance of the compiler itself.
rdar://24717107
This will allow control on the outside of these calls on whether or not LTO is
enabled. This is necessary for turning off LTO on target libraries.
rdar://24717107
