[Runtimes][CMake] Set up supplemental super-build #81006
Conversation
As we add libraries, it will become more tedious to manage building all of them independently. When built together, they should mostly take the same arguments specifying where they are installed, what compilers to use, and what configuration to use when building them. The super-build pattern is useful for this purpose. For certain distributions, it is useful to configure libraries with specific flags, but for most purposes, that is unnecessary. This moves the StringProcessing library to use the supplemental super build in CI.
etcwilde
requested review from
compnerd,
edymtt and
justice-adams-apple
as code owners
|
@swift-ci please smoke test |
| - 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
| - SwiftRuntime | |
| - Runtime |
There was a problem hiding this comment.
I assume that SwiftRuntime is actually Backtracing? If so, I think that we should clarify this as there is a SwiftRuntime in core as well.
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 Runtime module, which is why it is not just called Backtracing.
| if(SwiftCore_DIR) | ||
| set(SwiftCore_DIR_FLAG "-DSwiftCore_DIR=${SwiftCore_DIR}") |
There was a problem hiding this comment.
Should we use SwiftCore_ROOT instead? If I'm following the documentation properly, <PackageName>_DIR is supposed to be an env variable from an user perspective, and the matching cache variable is mostly managed by CMake itself (which can change it if invalid)
| if(SwiftCore_DIR) | |
| set(SwiftCore_DIR_FLAG "-DSwiftCore_DIR=${SwiftCore_DIR}") | |
| if(SwiftCore_ROOT) | |
| set(SwiftCore_ROOT_FLAG "-DSwiftCore_ROOT=${SwiftCore_ROOT}") |
| - Distributed | ||
| - Observation | ||
| - StringProcessing | ||
| - SwiftRuntime |
There was a problem hiding this comment.
I assume that SwiftRuntime is actually Backtracing? If so, I think that we should clarify this as there is a SwiftRuntime in core as well.
| ExternalProject_Add("${stdlib_target}-StringProcessing" | ||
| SOURCE_DIR | ||
| "${CMAKE_CURRENT_SOURCE_DIR}/Runtimes/Supplemental/StringProcessing" | ||
| ExternalProject_Add("${stdlib_target}-Supplemental" |
There was a problem hiding this comment.
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.
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_package to 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.
|
@swift-ci please smoke test Linux |
|
@swift-ci please smoke test Windows |
|
|
||
| set(COMMON_OPTIONS | ||
| -DBUILD_SHARED_LIBS=${BUILD_SHARED_LIBS} | ||
| -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE} |
There was a problem hiding this comment.
I added
-DCMAKE_INSTALL_LIBDIR=${CMAKE_INSTALL_LIBDIR}
-DCMAKE_INSTALL_NAME_DIR=${CMAKE_INSTALL_NAME_DIR}
-DCMAKE_BUILD_WITH_INSTALL_NAME_DIR=${CMAKE_BUILD_WITH_INSTALL_NAME_DIR}
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
|
Duplicate of #81179 |
Continue with #81006 Will land the common Cmake modules next before implementing Synchronization build
As we add libraries, it will become more tedious to manage building all of them independently. When built together, they should mostly take the same arguments specifying where they are installed, what compilers to use, and what configuration to use when building them. The super-build pattern is useful for this purpose. For certain distributions, it is useful to configure libraries with specific flags, but for most purposes, that is unnecessary.
This moves the StringProcessing library to use the supplemental super build in CI.
This is splitting out the super-build pattern form the Differentiation PR: #80513