CMake: SwiftCore Install Story #79548
Conversation
etcwilde
requested review from
compnerd,
edymtt and
justice-adams-apple
as code owners
|
@swift-ci please smoke test |
etcwilde
force-pushed
the
ewilde/stdlib-rebuild-install-story
branch
from
5124e7c to
37512a1
Compare
|
@swift-ci please smoke test |
|
@swift-ci please smoke test |
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.
etcwilde
force-pushed
the
ewilde/stdlib-rebuild-install-story
branch
from
37512a1 to
7870db6
Compare
|
Windows bot caught something. Neat. |
|
@swift-ci please smoke test |
| @@ -143,7 +143,6 @@ add_compile_definitions( | |||
| $<$<BOOL:${SwiftCore_ENABLE_OBJC_INTEROP}>:-DSWIFT_OBJC_INTEROP> | |||
| $<$<BOOL:${SwiftCore_ENABLE_LIBRARY_EVOLUTION}>:-DSWIFT_LIBRARY_EVOLUTION> | |||
| $<$<BOOL:${SwiftCore_ENABLE_CRASH_REPORTER_CLIENT}>:-DSWIFT_HAVE_CRASHREPORTERCLIENT> | |||
| $<$<BOOL:${SwiftCore_ENABLE_VECTOR_TYPES}>:-DSWIFT_STDLIB_ENABLE_VECTOR_TYPES> | |||
There was a problem hiding this comment.
To double check my understanding: are we pushing this setting to runtime and core because those are the only artifacts for which it makes sense?
There was a problem hiding this comment.
I moved it to the public interface of runtime so that it affects runtime and anything that links against it. The issue is that runtime is privately linked into core, so the macro won't get carried out to products that link against swiftCore externally.
Then I made it part of the INTERFACE of swiftCore. It doesn't get re-applied to swiftCore, but is forwarded to anything that links against swiftCore using the config file. This means that the overlays and supplemental libraries that are using this config file will also get the flag set without needing to do anything.
Adding an installation story, complete with a generated
SwiftCoreConfig.cmakefile that allows pulling the just-built standard library into the downstream projects usingfind_package(SwiftCore). This will make it easier to ensure that the overlays and supplemental libraries are built against the expected runtimes.This also separates out the development and runtime components to allow
installing just the runtimes without the headers.
Component List:
The runtime libraries that are required for running code.
These are the files needed to interface with the standard library while doing development.
These include the shims headers as well as the swift modules and swift interfaces.
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.
Note
We will need to clean up how we find shims. As it stands today, if the Swift shims are copied into the build directory next to the compiler as the current builds are, those will be picked up in addition to the shims from the standard library resulting in build failures due to duplicate
SwiftShimsmodules. Still looking for a way around that.