[stdlib][CMake] Build differentiation in new runtime build #80513
Conversation
Adding initial pass at the differentiation 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 hooks up a super-build pattern and enables building the Differentiation library as part of 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.
[Optional] Should we state this is not the C++ runtime that underpins SwiftCore? Or is it redundant since we are talking about Supplemental libraries?
There was a problem hiding this comment.
So in general, C++ runtimes can't be mixed, so it should match. In practice though, you can sometimes if you're careful. I'm leaving it vague because there are occasionally cases where we want a C++ interop runtime that isn't the same as the swiftCore runtime (but you have to be really careful to ensure that objects don't cross between the runtimes). I think eventually we should have swiftCore expose the C++ runtime that it was built against and default the C++ interop runtime to build for that one, but not there yet. Perhaps I should split some of the more administrative parts of this PR out into a separate PR though.
There was a problem hiding this comment.
I was not referring about the C++ runtimes used to link the Core libraries and the Supplemental ones -- my concern was about the names, since we have a target called swiftRuntime in the Core libraries
Maybe we should refer it directly with the correct name that outside developers would see
| - SwiftRuntime | |
| - Runtime |
| endif() | ||
| project(SwiftDifferentiation | ||
| LANGUAGES Swift C | ||
| VERSION 6.1.0${BUILD_NUMBER}) |
There was a problem hiding this comment.
Should we bump this to 6.2?
| VERSION 6.1.0${BUILD_NUMBER}) | |
| VERSION 6.2.0${BUILD_NUMBER}) |
| set(SwiftRuntime_SWIFTC_SOURCE_DIR "${PROJECT_SOURCE_DIR}/../../") | ||
|
|
||
| foreach(lib ${Swift_ENABLE_RUNTIMES}) | ||
| string(TOLOWER ${lib} name) |
There was a problem hiding this comment.
I don't see the benefit of using a different case in the SwiftRuntime_ENABLE_ variable -- I can see a value in keeping the same case, so it's easier to iterate on the expected libraries to e.g. call ExternalProject_Add accordingly.
There was a problem hiding this comment.
Should we land the super build files in a separate PR, and keep this only to land the Differentiation bits?
There was a problem hiding this comment.
Yeah, I think that might not be the worst idea.
|
Duplicate of #81239 |
This patch set adds the initial build for the differentiation library and creates a rudimentary super-build over the supplemental libraries.
The differentiation library depends on gyb, so I've pulled the gyb module from the Core project with some minor alterations to work in a shared build. That mostly means replacing the hard-coded project name with the
${PROJECT_NAME}variable when expanding variables. This is just a quick first-pass at getting the differentiation library build, but likely needs more flags to ensure that it's exposing the needed APIs and symbols.The super-build pattern uses a top-level CMake file to coordinate building one or more projects using
ExternalProject_Add. This implementation is rudimentary, only passing a few common variables to each sub-project to keep things simple and ensure that each project is built consistently with the same compilers against the same SwiftCore for the same target.