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.
The previous commit resulted in multiple targets that claimed to be
able to generate the directories in question. Instead, just create the
directories as a pre-build step for the targets that actually need
them. (This does keep the cleanup for the existing directory creation
target, though.)
More https://bugs.swift.org/browse/SR-10029
The way it was set up before worked for Ninja but not for Xcode, due
to me not listing the swiftmodule directories as actual outputs of the
create-directories target. The resulting fix here is actually simpler
and involves fewer processes anyway, so good for us.
https://bugs.swift.org/browse/SR-10029
* 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*
CMake defaults to using a special <package>_DIR for finding packages.
Prefer this to import the CMake package for LLVM/Clang/Swift rather than
custom paths.
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
CMake defaults to using a special <package>_DIR for finding packages.
Prefer this to import the CMake package for LLVM/Clang/Swift rather than
custom paths.
Include a missing CMake module in a couple of locations that we were
using the function. Simplify a condition to use `MATCHES` rather than
two `STREQUAL`.
Otherwise, we'll think we don't need to install the API notes.
No test because this configuration isn't (yet) tested publicly
anywhere, but it is being tested within Apple.
When we do standalone overlay builds, they should rely on these
layouts already being in the toolchain. (In particular, the target
is never created.)
No tests because this configuration isn't (currently) being tested
outside of Apple.
When building RelWithDebInfo, we would accidentally link against the debug
MSVCRT library rather than the release mode one resulting in memory corruptions.
This adds a new copy-legacy-layouts-${platform}-${arch} target for each
platform and architecture that the standard library is built for.
If the platform and architecture has a corresponding layout file in
stdlib/public/legacy_layouts/${platform}/layouts-${arch}.yaml, the
target copies this file to the build directory; otherwise, it does
nothing.
When building Swift code, the subroutines in SwiftSource.cmake add a
dependency on this target from each Swift code target.
Finally, we ensure that the YAML files are copied into the toolchain
package when building a toolchain.
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.
Once upon a time we tried to use this to limit the visibility of
symbols in the Swift runtime in a way that didn't really make sense.
Dave Z removed it last year in 91823273d2.
No functionality change.
