The testee of xctest_add_bundle

Development
1

I’ve been working on a little package that could be thought of as a modernization of FindXCTest, which is a bit dated at this point. FindXCTest only supports Apple platforms, but XCTest is now available on Windows and Linux as part of Swift distributions. And the support for Apple platforms is outdated or incomplete, as these workarounds are needed to make it work with Swift.

My package uses FindXCTest on Apple platforms, and from it, inherits a “testee” parameter requirement… but this requirement seems a bit suspect. Swift Package Manager (for example) lets me declare and run XCTest targets with no testee, so it seems like a testee must not be inherently needed. In fact, the testee plays no special role as far as I can tell: SwiftCMakeXCTesting itself creates an empty dummy testee just to satisfy this requirement. Looking at the source code of FindXCTest is even more revealing:

  • The code supports the use of a static library as the testee, and my tests indicate that passing a static library target does in fact work , even though the documentation clearly forbids it.
  • The only interesting thing that happens with library testees—once their (seemingly needless) framework requirement is validated, if the library is shared—is that they are linked into the test target being declared with target_link_libraries. But that’s the sort of thing you would have to do with any other library dependency of the test, and it’s very common for my tests to depend on more than one library, so I’ll be making other calls to target_link_libraries. It seems weird to give this one library dependency special status.
  • That leaves application testees, for which there is some special logic, which looks like it’s what’s needed to treat an application bundle as a library. That seems like a generally-useful (but platform-specific) bit of functionality that ought to be vended as its own “thing,” independent of testing.

My inclination at this point is to stop relying on xctest_add_bundle and replicate the key parts of its functionality in my own package, freeing my APIs from the idea of a “testee,” but a) that seems like a shame, and b) I’m concerned I might be overlooking something. So

  • Can anyone shed light on the rationale for the current design?
  • Does my proposed approach make sense, or is there a better way?

Thanks!

1 Like
2

Cc: @gjasny

See https://gitlab.kitware.com/cmake/cmake/-/issues/16636

3

Thanks @ben.boeckel; I followed the link. It shows the commit that added the cmake code I was referring to that supports static libraries (without fixing the documentation to allow their use). I feel like you were maybe trying to say something more though. Was following the link supposed to reveal anything else of relevance?

4

No, sorry. This is not my field; I Cc’d Gregor Jasny who started the module and then provided context on the static library bit. I’ve not enough background to understand what pros and cons might be around it (sorry, I should have been more explicit).

5

In that case, @gjasny your input here would be most welcome.