[Runtimes][CMake] Set up supplemental super-build #81006
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| @@ -0,0 +1,44 @@ | ||||||||||
| cmake_minimum_required(VERSION 3.29) | ||||||||||
|
|
||||||||||
| project(SwiftRuntime LANGUAGES Swift C CXX) | ||||||||||
|
|
||||||||||
| include(ExternalProject) | ||||||||||
|
|
||||||||||
| set(SwiftRuntime_SWIFTC_SOURCE_DIR "${PROJECT_SOURCE_DIR}/../../") | ||||||||||
|
|
||||||||||
| foreach(lib ${Swift_ENABLE_RUNTIMES}) | ||||||||||
| string(TOLOWER ${lib} name) | ||||||||||
| set(SwiftRuntime_ENABLE_${name} YES) | ||||||||||
| endforeach() | ||||||||||
|
|
||||||||||
| if(SwiftCore_DIR) | ||||||||||
| set(SwiftCore_DIR_FLAG "-DSwiftCore_DIR=${SwiftCore_DIR}") | ||||||||||
|
Comment on lines
+14
to
+15
There was a problem hiding this comment. Should we use
Suggested change
|
||||||||||
| endif() | ||||||||||
|
|
||||||||||
| if(CMAKE_MAKE_PROGRAM) | ||||||||||
| set(MAKE_PROGRAM_FLAG "-DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}") | ||||||||||
| endif() | ||||||||||
|
|
||||||||||
| set(COMMON_OPTIONS | ||||||||||
| -DBUILD_SHARED_LIBS=${BUILD_SHARED_LIBS} | ||||||||||
| -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE} | ||||||||||
|
There was a problem hiding this comment. I added In my synchronization PR so the supplemental super build could pass those through (assuming each uses the same install destination). Not sure if that's the best approach but it's similar to install_prefix |
||||||||||
| -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> | ||||||||||
| -DCMAKE_COLOR_DIAGNOSTICS=${CMAKE_COLOR_DIAGNOSTICS} | ||||||||||
| -DCMAKE_C_COMPILER=${CMAKE_C_COMPILER} | ||||||||||
| -DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER} | ||||||||||
| -DCMAKE_Swift_COMPILER=${CMAKE_Swift_COMPILER} | ||||||||||
| -DCMAKE_C_COMPILER_TARGET=${CMAKE_C_COMPILER_TARGET} | ||||||||||
| -DCMAKE_CXX_COMPILER_TARGET=${CMAKE_CXX_COMPILER_TARGET} | ||||||||||
| -DCMAKE_Swift_COMPILER_TARGET=${CMAKE_Swift_COMPILER_TARGET} | ||||||||||
| ${SwiftCore_DIR_FLAG} | ||||||||||
| ${MAKE_PROGRAM_FLAG}) | ||||||||||
|
|
||||||||||
| # StringProcessing | ||||||||||
| if(SwiftRuntime_ENABLE_stringprocessing) | ||||||||||
| ExternalProject_Add(StringProcessing | ||||||||||
| SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/StringProcessing" | ||||||||||
| INSTALL_DIR "${CMAKE_INSTALL_PREFIX}" | ||||||||||
| INSTALL_COMMAND "" | ||||||||||
| CMAKE_ARGS | ||||||||||
| ${COMMON_OPTIONS}) | ||||||||||
| endif() | ||||||||||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,52 @@ | ||||||
| # Swift Supplemental Libraries | ||||||
|
|
||||||
| The supplemental libraries are all libraries that are not one of the Core or | ||||||
| overlay libraries. Each supplemental library builds as an independent project. | ||||||
|
|
||||||
| The supplemental libraries are: | ||||||
| - CxxInterop | ||||||
| - Differentiation | ||||||
| - Distributed | ||||||
| - Observation | ||||||
| - StringProcessing | ||||||
| - SwiftRuntime | ||||||
|
There was a problem hiding this comment. I think we should use the user visible name, not the one we need to specify in the CMake code
Suggested change
There was a problem hiding this comment. I assume that There was a problem hiding this comment. I think @al45tair was planning on exposing more of the lower-level runtime code to Swift through this module, not just backtracing. This is referring to the RuntimeModule portion of the stdlib though. There was a problem hiding this comment. Yes. There are other things that I (and others) would like to put into the |
||||||
| - Synchronization | ||||||
|
|
||||||
| The top-level Supplemental CMakeLists supplies a super-build pattern for | ||||||
| configuring and compiling each of the supplemental library projects through a | ||||||
| single CMake invocation. The `Swift_ENABLE_RUNTIMES` CMake option enables the | ||||||
| specified supplemental libraries. All libraries configured this way are built | ||||||
| with the same compilers, against the same sysroot, with the same target triple | ||||||
| and installed into the same location. | ||||||
|
|
||||||
| ## Super-Build | ||||||
|
|
||||||
| Configuring each project independently is tedious. The Supplemental directory | ||||||
| contains a Super-Build CMakeLists that invokes the build of each of the | ||||||
| supplemental libraries in the appropriate order, simplifying the process of | ||||||
| building each library. | ||||||
|
|
||||||
| Important configuration variables: | ||||||
| - `Swift_ENABLE_RUNTIMES`: Used to configure which runtime libraries are built. | ||||||
|
|
||||||
| The super-build forwards the following variables to each sub-project | ||||||
| unconditionally: | ||||||
| - `BUILD_SHARED_LIBS` | ||||||
| - `CMAKE_BUILD_TYPE` | ||||||
| - `CMAKE_INSTALL_PREFIX` | ||||||
| - `CMAKE_COLOR_DIAGNOSTICS` | ||||||
| - `CMAKE_C_COMPILER` | ||||||
| - `CMAKE_C_COMPILER_TARGET` | ||||||
| - `CMAKE_CXX_COMPILER` | ||||||
| - `CMAKE_CXX_COMPILER_TARGET` | ||||||
| - `CMAKE_Swift_COMPILER` | ||||||
| - `CMAKE_Swift_COMPILER_TARGET` | ||||||
|
|
||||||
| If set, the super-build forwards the following values to each sub-project: | ||||||
|
|
||||||
| - `SwiftCore_DIR`: Path to the SwiftCore build directory | ||||||
| - `CMAKE_MAKE_PROGRAM`: Path to `ninja` | ||||||
|
|
||||||
| The super-build is for convenience. If more fine-grained control is desired for | ||||||
| configuring a specific runtime library, you may configure that library | ||||||
| independently. | ||||||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that this is a stronger reason to setup a proper build in Supplemental. We are now doing two levels of external project :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are good reasons to not turning Supplemental into one large project. Not every distribution wants/needs all of the libraries and we have a history of not being great about tracking what can be masked out of the build together resulting in broken builds, for instance. The split projects mean that each library is responsible for using
find_packageto pull in the other bits that they depend on or they'll fail to link, ensuring that the dependencies don't get out of sync and we can continue to build/configure each piece independently. The current structure also ensures that each library can be built independently if you're using a build system that allows splitting the projects across machines. Much like the LLVM_ENABLE_RUNTIMES variable, the super build (and configuring the runtime build through the same CMake invocation as the compiler) is a convenience.