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.
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.
...because the Darwin overlay is responsible for installing them.
Context: Within Apple, overlays are sometimes built separately from
the rest of the Swift project. This doesn't currently work with just
the public repo (rdar://problem/47324189), but it could, and I broke
it with my recent API notes cleanup. This should get things working
again.
rdar://problem/47294352
Previously, build-script-impl would set this to "" by default, resulting
in nothing being installed with --install-swift unless you explicitly
set --swift-install-components as well. Now we defer to cmake by
default.
On the cmake side, change the default value to exclude
* dev - uses a lot of disk space and usually not something you want to
install into a toolchain
* clang-resource-dir-symlink & clang-builtin-headers-in-clang-resource-dir -
these are mutually exclusive with clang-builtin-headers
* sourcekit inproc/xpc - these are currently mutually exclusive, so pick
the best one for the current platform.
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.
This converts the path separators to the CMake way. This is primarily
important for Windows where the path separator is \ rather than /. This
conversion allows the specification of the path in the proper windows
path style.
