[cmake] Build swift-testing with CMake. #387
Conversation
jeffdav
requested review from
stmontgomery,
grynspan,
dennisweissmann,
briancroom,
SeanROlszewski and
suzannaratcliff
as code owners
grynspan
added
enhancement
|
Thank you @jeffdav! Appreciate the helpful contribution. I have several comments so far and will take a second pass tomorrow |
|
Open question: how do we test this change? |
|
@jeffdav Could we ask you to just push additional commits so it's easier for us to see incremental changes? We'll squash the whole thing when we merge the PR. Thanks! |
|
No problem. I wasn't sure what the right thing to do was. I'd honestly prefer incremental diffs. :) |
|
Oh, but github does have a little "compare" link next to each force-push, which I hadn't realized. |
|
Something else for you to consider: we should have instructions somewhere (perhaps in a dedicated .md file in Documentation/) showing how to build swift-testing from source using CMake. |
Added. I'd love feedback on the documentation (consider this a 1st draft). |
|
@grynspan any further concerns on your side? |
|
Nope, I defer to @etcwilde here. (FYI we don't use Swift's C++ interop feature, so its lack of support for exceptions doesn't make a difference to us. However, we also don't throw any exceptions or intend to catch any, so it's moot.) |
|
Oh—please update the file lists before merging. There are a number of new files added since you opened this PR. |
Done! |
|
@swift-ci please test |
|
@jeffdav I know you folks obviously work with Windows. The Windows failure we're seeing is a compiler bug unrelated to your PR. If you're comfortable with merging the PR despite the failure, we can proceed. (I'm unsure if you can see a merge button—if not, ping me and I'll do it.) |
Yeah, I'm familiar with that compiler bug for other reasons. :) |
|
@grynspan Thanks for your help! I don't have a merge button. |
|
@swift-ci please test |
…KE' (#554) This removes the `SWT_BUILDING_WITH_CMAKE` compilation condition, and the `@_implementationOnly import _TestingInternals` declarations it guards. ### Motivation: When support for building via CMake was first added (in #387), many source files in the `Testing` target were modified to avoid using `private`- or `internal`-level imports of the `_TestingInternals` module and instead use the older `@_implementationOnly import` style when building via CMake. As a result, many files have: ```swift #if SWT_BUILDING_WITH_CMAKE @_implementationOnly import _TestingInternals #else private import _TestingInternals #endif ``` This has proven to be a maintenance problem for us, because as new files are added over time, it's not immediately obvious that they need to use this pattern for importing this module—leading to warnings when building with CMake such as the one fixed by #553. I wasn't aware of the reasoning behind the above change at the time, but I investigated it recently and here's what I concluded: Early on, the changes in #387 did _not_ enable Library Evolution (LE) for the `Testing` module, meaning it was still a non-resilient module. [SE-0409](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0409-access-level-on-imports.md) states that all dependencies of non-resilient modules must be loaded by clients, so it would make sense that under those conditions, the build of a client who imports `Testing` would fail because clients do not have visibility to the `_TestingInternals` module. However, in a later PR commit LE was enabled, but nobody realized that those `import` code changes were no longer necessary and could be reverted. I was able to reproduce this and confirm the theory: I added an example client target in the CMake build, then disabled LE in the `Testing` module, and attempted to build the client. It failed with the expected missing module error. Then, re-enabling LE and rebuilding everything, the error went away. Hopefully this is sufficient proof that reverting this is safe, but I'll check with the main contributor of that PR to check and see if there were any other issues before landing. But overall, the goal here is to simplify these imports to reduce maintenance burden and fully embrace SE-0409. ### Checklist: - [x] Code and documentation should follow the style of the [Style Guide](https://github.com/apple/swift-testing/blob/main/Documentation/StyleGuide.md). - [x] If public symbols are renamed or modified, DocC references should be updated.
Add files needed to build swift-testing with CMake.
Motivation:
Being able to build with CMake is useful in many scenarios. The immediate need is to bring
swift-testingto Windows. To do so we need to support a non-SPM path to allow building targets that would otherwise hit the export symbol limit on Windows.Modifications:
Testing,TestingInternal, andTestingMacros.TestingMacrosas anExternalProjecttargeting the build machine.SwiftTesting_GenerateDerivedSourceswhich generates arunner-swift-testing.swiftand returns a variable that allows consumers to compile it with their sources.Result:
swift-testingwith CMake. Example command lines:cmake -S . -B b -G Ninja -D CMAKE_CXX_COMPILER=clang cmake --build .\bswift-webdriverto useswift-testingvia CMake.Checklist: