Otherwise certain modules don't import correctly when built against an
Apple-internal SDK. Should have no effect when using the public SDK,
but we try to minimize divergence between the public and
Apple-internal test suites.
rdar://problem/48513002
This turns out to be the only problem on iOS and tvOS. Oops! macOS
still has some actual failing overlays as tracked by SR-9847.
(We should also add this search path to
ParseableInterface/verify_all_overlays.py.)
rdar://problem/48458622
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
