Automatically determine the testing library version instead of hardcoding it, including for release branches

[stmontgomery]

Description

This issue tracks finding a way to stop hardcoding the Swift Testing library version in places like

https://github.com/swiftlang/swift-testing/blob/main/cmake/modules/LibraryVersion.cmake#L11

Instead, for CMake builds driven by build-script, I think we could use the propagated -DSWIFT_VERSION and related settings to infer the version from the surrounding build.

Motivation: Avoid needing to perform the manual maintenance task of bumping the version, such as in https://github.com/swiftlang/swift-testing/pull/1061

Additional information

No response

[stmontgomery]

For reference, I looked at a randomly chosen Swift CI log (link) and saw -DSWIFT_VERSION=6.2.

[grynspan]

That's not quite what we need here as we also distinguish dev builds.

[stmontgomery]

Yeah, I mentioned "and related settings" above. My point is that I think there may be sufficient info plumbed through, of if there isn't quite enough (such as dev), then at least there may be a precedent to follow to allow us to plumb a little more.

[grynspan]

Rather, our string here is ideally the same as the one produced by swift --version (minus the hashes, probably). swift-driver has enough information at compile time to construct that string statically, which suggests it's available to the toolchain at build time. Ideally we'd get the string from the same source.

Did you file a bug on the main swift repo to vend that string/info to CMake?

[grynspan]

If CMake can see the branch we're building from is release/*, that may be sufficient info for us to drop -dev.

[stmontgomery]

Tracked by rdar://148830438