* [build] use generator expression only on CMake > 3.15
In CMake < 3.16, Generator expressions seem not to allow the `LINKER:` prefix to be
expanded correctly when used in `target_link_options`.
To account for this, account for two code paths according to CMake version -- use the generator expression when detecting we are on 3.16 and resort to an if statement otherwise
Addresses rdar://problem/59117166
The `FILE_DEPENDS` option is used in exactly one location: swiftCore.
This prevention sets the groundwork for removing the option.
Dependencies should be tracked at the target level.
Hoist the responsibility for adding the linked libraries out of
`_add_swift_executable_single` to the invoker. This impacts only
`swift_add_target_executable`. This continues to bring the computation
of the properties nearer the site of definition.
Due to some unfortunate interplay between clang and libstdc++, clang was
not able to correctly identify to alignment of PoolRange and
SideTableRefCountBits, causing it to emit library calls instead of
inlining atomic operations. This was fixed by adding the appropriate
alignment to those types. In addition to that the march for the Linux
target was set to 'core2', which is the earliest architecture to support
cx16, which is necessary for the atomic operations on PoolRange.
Collate -F with the framework path to avoid unwanted deduplication of options by `target_compile_options` (which is the case after #29451) -- this way no undesired side effects are introduced should a new search path be added.
Addresses rdar://problem/58934566
Before the result of `_add_variant_c_compile_flags` was a string, so appending several "-isystem" was not a problem. With #29451 the rules have changed since the list is now handled by CMake, and it deduplicates the repeated members in the list. Thanks, CMake.
Should fix the Android CI builds that were failing since the merging of #29451.
This should repair the Windows build after #29451. The quoting
behaviour was incorrect and was constructing an invalid compiler
invocation. Solve the issue by using `target_include_directories`
instead. However, since this needs the target, hoist the flag
computation to the local sites. This replicates more logic because of
the custom build trying to replicate the CMake build logic in CMake.
This simplifies the ICU flags handling. This inlines the use into just
the library case, as the ICU usage is for the standard library targets
only. It uses CMake to properly add the include paths as a system
search path. This should fix the Linux builds as the include flags were
being de-duplicated as we are now using CMake more than we were
previously.
This was introduced in 2014. This should not be needed any longer,
especially with the use of the clang dependencies being satisfied by
export targets through `Clang_DIR`.
Use specific operations for setting the compile flags, link flags,
linked libraries, and library search paths. This allows us to use CMake
more effectively, simplifies the logic, and will ensure that flags are
not duplicated.
`EXCLUDE_FROM_ALL` should be discouraged. `ALL` should build *all*
targets. If a subset of targets are desired to be built, we should
provide targets which make sense. Sink the single use of this flag
into the standard library setup. The custom cross-compilation was
the reason that the flag was plumbed all the way through. Cleaning
up the macros that have been built up is needed to migrate towards
proper cross-compilation support.
This is used in two places. Rather than plumbing the option through
everywhere, set the two locations to use compiler-specific optimization
flags. Note that this improves the optimizations enabled for the debug
build with an optimized type-checker.
This also clears the way to have `add_swift_host_library` be entirely a
trivial wrapper over `add_library` enabling us to finally move towards
more standard CMake rules.
This commit adds initial build system support for macCatalyst,
an Apple technology that enables code targeting iOS
to be recompiled so that it can be executed on macOS while still using
iOS APIs. This is the first in a series of commits building out support for
macCatalyst in the compiler, runtime, standard library, and overlays. Swift
for macCatalyst represents the work of multiple people, including
Devin Coughlin, Ross Bayer, and Brent Royal-Gordon.
Under macCatalyst, compiler-provided shared libraries (including overlays)
are built as one of four kinds (or "flavors") of libraries,
each with different install names and Mach-O load commands. This commit
adds the build system infrastructure to produce these different
library flavors.
**macOS-like Libraries**
A "macOS-like" library (such as the GLKit overlay) is a plain-old macOS library
that can only be loaded into regular macOS processes. It has a macOS slice with
a single load command allowing it to be loaded into normal macOS processes.
**iOS-like Libraries**
An "iOS-like" library, such as the UIKit overlay, is a library with a
macOS slice but with a load command that only allows it be loaded into
macCatalyst processes. iOS-like libraries are produced by passing a new
target tuple to the compiler:
swiftc ... -target x86_64-apple-ios13.0-macabi ...
Here 'ios' (and an iOS version number) is used for OS portion
of the triple, but the 'macabi' environment tells the compiler
that the library is intended for macCatalyst.
**Zippered Libraries**
A "zippered" library can be loaded into either a macCatalyst process or
a standard macOS process. Since macCatalyst does not introduce a new Mach-O
slice, the same code is shared between both processes. Zippered libraries
are usually relatively low level and with an API surface that is similar
between macOS and iOS (for example, both the Foundation overlay and the Swift
Standard Library/Runtime itself are zippered).
Zippered libraries are created by passing both the usual `-target`
flag to the compiler and an additional `-target-variant` flag:
swiftc ... -target x86_64-apple-macos10.15 \
-target-variant x86_64-apple-ios13.0-macabi
Just like the -target flag, -target-variant takes a target tuple.
This tells the compiler to compile the library for the -target tuple but
to add an extra load command, allowing the library to be loaded into processes
of the -target-variant flavor as well.
While a single zippered library and slice is shared between macOS and
macCatalyst, zippered libraries require two separate .swiftinterface/.swiftmodule
files, one for macOS and one for macCatalyst. When a macOS or macCatalyst client
imports the library, it will use module file for its flavor to determine what
symbols are present. This enables a zippered library to expose a subset of its
target APIs to its target-variant.
**Unzippered-Twin Libraries**
"Unzippered Twins" are pairs of libraries with the same name but different
contents and install locations, one for use from macOS processes and one for
use from macCatalyst processes. Unzippered twins are usually libraries that
depend on AppKit on macOS and UIKit on iOS (for example, the MapKit overlay)
and so do not share a common implementation between macOS and macCatalyst.
The macCatalyst version of an unzippered twin is installed in a parallel
directory hierarchy rooted at /System/iOSSupport/. So, for example, while macOS
and zippered Swift overlays are installed in /usr/lib/swift/, iOS-like and
the macCatalyst side of unzippered twins are installed in
/System/iOSSupport/usr/lib/swift. When building for macCatalyst, the build system
passes additional search paths so that the macCatalyst version of libraries is
found before macOS versions.
The add_swift_target_library() funciton now take an
optional MACCATALYST_BUILD_FLAVOR, which enables swift libraries to indicate
which flavor of library they are.
