XCTest installation location on Windows

I guess, this question is mostly addressed to @compnerd as the author of toolchain builds, but after seeing some discussions on this forum about the toolchain directory layout, I think this might be interesting to more folks.

The question is:
Why is XCTest installed into a special XCTest-development directory, and not under SDKs/Windows.sdk with the rest of the SDK?

SDK's Info.plist file has an XCTEST_VERSION entry, but what's the purpose of additional versioning for XCTest binaries? In the Linux toolchains there doesn't seem to be a separate XCTest version, so I'm curious if there's a Windows-specific reason for it, or it just hasn't landed on Linux yet.

Would appreciate any insight :slight_smile:

XCTest is not part of the SDK technically - it is not part of the platform nor the redistributables. It is a supporting developer library meant to be used for testing.

You are not guaranteed that the library is going to be available for all platforms either. Consider a case such as developing on (build) Windows x64 for (host) AArch64. In such a case, the binaries built for AArch64 will not run on x64. However, were you to build your AArch64 code for x64, it would use the developer support library for running the tests. The toolchain layout reflects that state.

You can find some of the rationale here, and if you have suggestions on how to improve the explanations there, I am more than happy to adjust that documentation. If others would prefer that this documentation be merged into the swift repository, if there is a reasonable place to do so, I would be okay with moving the documentation.

There was a significant amount of work to be done (and arguably still is, as new stuff has taken the place of completed work :sweat_smile:). One of the pieces of work there is that -development is not truly meant for release versions, but its not easy to wire through the version information as of yet in the build process. The desire here is that the appropriate version (5.3, 5.4, 5.4.1, etc) would be used instead of -development for the particular release as XCTest is built at those specific versions. For the snapshots, because there is no version associated with them, and instead are treated as "development" snapshots. The argument to use 9999 as a version number is a separate argument (and has its own merits).

However, nothing precludes the parallel installation of XCTest 5.3 and 5.4.1 for example. The intent here was to keep the possibility open to have parallel installation of XCTest should the need ever arise.

The Info.plist file simply directs SPM to a version of XCTest. This is to avoid hardcoding that information into SPM itself. However, should enough work ever occur (I'm looking at you swift-devenv) this would be something that with parallel installations would be configurable so that different versions of XCTest could be used.

If I have missed anything, please let me know and I can try to expand on that further.

1 Like

Thanks for your reply @compnerd!

The document you've linked, in combination with the cross-compilation argument, answers the question.
Specifically, if Windows versioning is added to the SDK names (Windows-10.0.17763.0.sdk instead of Windows.sdk), that would provide an alternative way to have multiple versions installed over just having several toolchain roots with all the components inside them. With this approach having XCTest versioning also seems to be a good idea.

There is definitely interest from myself in seeing the versioning, its more a matter of practical considerations - needing to setup the MSI rules and wiring the information into the various points. All of the pieces are meant to be parallel installable (toolchain, SDK, and support libraries).

Terms of Service

Privacy Policy

Cookie Policy