Before #82571, we would generate a binary swiftmodule file at `<build
folder>/<module>.swiftmodule`, while now in the same location we
generate a directory.
Trying an incremental run on top of a build folder generated with the
old logic will fail during configuration with an error similar to
```
CMake Error at .../Supplemental/cmake/modules/EmitSwiftInterface.cmake:21 (file):
file failed to create directory:
.../StringProcessing-build/_RegexParser/_RegexParser.swiftmodule
because: File exists
```
To reduce churn in CI and at desk, delete such remnant from the previous
logic.
Addresses rdar://155466197
Extract the `install_swift_interface` function into a new file. This
is always invoked to perform the installation of the Swift interfaces as
well as the binary module. Additionally, it prepares for a future
refactoring which will also install the swift documentation interface.
Starting to work on a full installation story for the Swift runtimes.
This involves generating the SwiftCoreConfig cmake files to allow
importing the just-built runtimes into the overlays and supplemental
libraries, setting up the flags appropriately for the given SwiftCore
build configuration.
This also separates out the development and runtime components to allow
installing just the runtimes without the headers.
Component List:
- SwiftCore_runtime
The runtime libraries that are required for running code.
- SwiftCore_development
The interface with the runtime libraries that are required for
building code against the runtimes.
- SwiftCore_cmake
Files for interfacing CMake projects with the built runtimes.
This includes the target list and flags needed to use the targets
built by the specific configuration used to build the runtime
libraries.
These files are used for mapping flags, definitions, and locations
into the overlay libraries and supplemental libraries.
This adds install commands for the object libraries contributing to
libswiftCore so that they are represented in SwiftCoreTargets.cmake.
Object libraries do not contribute anything to the files actually
installed.
To keep things consistent with the target and target-variant swiftmodule
files, moving the installation of the binary swift module into
`install_swift_interface`. CMake implicitly generates the target
swiftmodule, but does not know about zippered binaries, so we need to
ensure that the target-variant module is available for installation when
applicable.
In some configurations, libraries are installed under
`<install-prefix>/{libdir}/swift/<platform>/<arch>` and module content
is installed under `<install-prefix>/{libdir}/swift/<platform>`.
This also accounts for the fact that Swift currently looks under
`<install-prefix>/{libdir}/swift_static/**` for the static stdlib
builds.
This patch hooks up the swiftCore library build and gets it installing.
This means that we have library evolution hooked up and vector types.
Building it dynamically found that we had duplicate symbols, so fixed
the swiftDemanglingCR library.
Needed to hook up the availability macros.
The flag configuration is for macOS, so we'll need to go through and
figure out what it should look like for the other platforms too.
