Adjust the `c_compile_flags` variable to ensure that the flags are ordered
correctly. This is of import for the android build which may end up using
invalid header search path ordering otherwise. This ensures that the path
for the ICU includes comes after the C++ headers which is necessary in new
C++ releases which shadow math.h
Move the ICU flag handling to the same area as `_c_compile_variant_flags` which
computes the C compile flags. This allows us to ensure that we order the flags
correctly when they are merged into the `c_compile_flags`.
The CMake variables ${sdk} and ${arch} are only set if
_add_variant_link_flags is invoked from add_swift_target_library calling
_add_swift_library_single. If you get to _add_swift_library_single from
add_swift_host_library, those variables will not be set and subsequent
linking will not find ICU libraries. This was an issue when building
swift host libraries on Android.
This was used for the swift-reflection-test tool. Instead of using fat
binaries, use the target binary itself. This simplifies the build logic
as well as paves the road to sub-builds for each target rather than a
monolithic build as we have today.
Originally, the swift-reflection-test was a host tool that linked
against the target libraries since it was testing the target layout.
Now that the tool has been split into a host and target component
(5ea5bb06a3) and we have target and host
libraries that we can link against appropriately, we do not need to link
against the FAT binary. Since there was exactly one use of this
functionality, switching that from fat linking to regular linking allows
us to remove this functionality entirely. Switch to regular linking and
remove the option.
This avoids us having to pattern match every source file which should
help speed up the CMake generation. A secondary optimization is
possible with CMake 3.14 which has the ability to remove the last
extension component without having to resort to regular expressions. It
also helps easily identify the GYB'ed sources.
This is not currently being used. Unfortunately, setting linker options
is difficult until CMake 3.13 which introduced target_link_options.
Prior to that, you needed to do:
set_property(TARGET <TARGET> APPEND_STRING LINK_FLAGS <NEW FLAGS>)
If needed, we could write a helper to provide the target_link_options
interface on earlier CMake versions.
Whenever we're building C++ code as part of the Swift runtime or overlays,
disable the ABI-breaking checks. We are only using header content from
LLVM's ADT library.
Fixes rdar://problem/48618250.
* Enable linker dead stripping on Darwin
See r://48283130. This shaves 6MB+ off of swift and SourceKitService,
26.8MB off of swift-llvm-opt, 29.4MB off sil-passpipeline-dumper, etc.
* Disable dead stripping in Debug builds
It can hide linker errors caused by dependency cycles.
Unfortunately, `swift-reflection-test` links against the *TARGET*
library `swiftRemoteMirror`. The linked library is built as a target
library, which means that we use the custom library target construction
which suffixes the target with a variant spelling. Because the number
of variants is really high, we pass along the explicit EXPORTS macro
manually. However, we also build the library as a static library for
the *HOST*. This means that we need the sources to be aware of whether
they are built statically or dyanmically. This is accomplished by means
of the `_WINDLL` macro. The target library is shared and is built using
the custom wrapper for the library construction, which will create all
the variants and then use `_compute_variant_c_flags` which does not get
told what type of library is being built, so it assumes static and does
not append `_WINDLL`. This results in the shared library not exposing
any interfaces on Windows. When this happens, link will helpfully elide
the import library. The result of that is that the
swift-reflection-test binary will fail to link due to no import library
for the RemoteMirror. Explicitly add the -D_WINDLL if appropriate
manually after we have computed the C flags. *siiiiiiigh*
This changes the Swift resource directory from looking like
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
x86_64/
Swift.swiftmodule
Swift.swiftdoc
Darwin.swiftmodule
Darwin.swiftdoc
to
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
Swift.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
Darwin.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
matching the layout we use for multi-architecture swiftmodules
everywhere else (particularly frameworks).
There's no change in this commit to how Linux swiftmodules are
packaged. There's been past interest in going the /opposite/ direction
for Linux, since there's not standard support for fat
(multi-architecture) .so libraries. Moving the .so search path /down/
to an architecture-specific directory on Linux would allow the same
resource directory to be used for both host-compiling and
cross-compiling.
rdar://problem/43545560
When building RelWithDebInfo, we would accidentally link against the debug
MSVCRT library rather than the release mode one resulting in memory corruptions.
This adds an explicit version of the SwiftRemoteMirror library for use
in the tools that comprise the toolchain. This is a separate build from
the target specific builds of the library even though we may be building
the runtime for the (same) host.
This fixes using --install-swift on macOS when not building all of the
variant stdlibs (e.g. iphonesimulator, etc.).
When we build swift on macOS, by default we build only the macOS stdlib.
The other stdlib variants are still configured and there are targets to
build them if you e.g. run `ninja swift-stdlib-iphonesimulator-x86_64`
manually. However, we do not separate the _install_ actions. This
meant that you couldn't install without building all the configured
stdlib variants.
They're all the same anyway, and no longer even need to be compiled,
just copied in as text.
And drastically simplify how we "generate" them. Instead of attaching
their build jobs to the appropriate overlays, if present, "just" have
one job to copy them all and attach it to the Darwin overlay. That's
what we do for the overlay shim headers, and it's good enough.
(Eventually we want to get out of the business of shipping them
altogether.)
This does have the same flaw as the shim headers: if you /just/ change
API notes, the corresponding overlay does not get rebuilt. You have to
touch that too. But in practice that'll happen most of the time
anyway.
Part of rdar://problem/43545560
Colocate the target specific library specification. Inline the single
site use of the place holder ICU_UC and ICU_I18N libraries rather than
trying to create special library processing code for that.
Windows does not support fat binaries, so the target specific components should
be placed into the architecture subdirectory. Due to the cross-compilation
model that swift has, this needs to be added explicitly for now.
This improves the integration with LLVM and the unified build. The
LLVM_INSTALL_TOOLCHAIN_ONLY flag ensures that the the development libraries are
not installed. Because this option is not defined by default, the beahavioural
changes here are not triggered by default.
Due to the horrible attrocities against software of the attempt to perform
cross-compilation in the swift build system, we need to emulate the linking
behaviour for Windows with the link against the import library. The emulation
requires the custom creation of import library targets. In order to actually
get the linking semantics correct, the dependendency targets must be created
prior to use (unlike standard CMake). The reordering ensures that we get
correct linkage when building for Windows.
Perform a simple optimization to avoid a number of string comparisions for the
host system.
Normally, the C++ shared library would have link against the C++ ABI
shared library, but the Android NDK does not distribute the later, so
one need to link manually against the static C++ ABI from the NDK.
This will ensure that additional target executables can not be added to the rest
of the swift project without anyone noticing since the non-stdlib parts of
Swift's cmake will not have visibility of the declaration unless they change the
cmake lookup paths.
The swift image registrar uses the extension `.obj` as is traditional on
Windows. Ensure that we get the extension correct when cross-compiling with the
Swift specific cross-compilation system.
