FindGTest always links "Threads::Threads" to target "GTest::GTest"

Development
1

Hey everyone,

in case find_package(GTest) successfully imports the GTest::GTest target via the FindGTest.cmake module (and no matching gtest config script could be found), Threads::Threads is always added as interface link library to the imported gtest target (see here).
However, this may not always be the correct case, because gtest can be built without pthreads support (see cmake option gtest_disable_pthreads).

While I understand the reasoning behind the decision to always link against Threads::Threads - how would the find script know whether gtest was built with thread support or not, so it doesn’t hurt to always link it - it may hide subtle bugs in the code under test:
In my case, one component forgot to add Threads::Threads as public link dependency for the INSTALL_INTERFACE and only populated it via the BUILD_INTERFACE. By implicitly linking the Threads::Threads target to the GTest::GTest target, -lpthread was always appended by the linker, hiding the missing dependency in the test executables and leading to undefined references in customer code.

I’m not quite sure whether this can be addressed in any way, but it would be nice to have a way to disable this behavior. Maybe by adding a new CMake variable to affect that behavior (e.g. GTEST_DISABLE_PTHREADS=ON|OFF with a default value OFF for backwards compatibility).

If not, maybe someone has a hint how to disable the implicit link dependency?

Thanks,
René.

2

FindGTest would need to learn how to inspect whether it is needed or it could be hinted with such a variable, yes.

3

Any idea how FindGTest could learn that? It seems like the cleaner solution, but wouldn’t be easy to implement I guess.

4

Is there some way to tell if libgtest needs pthreads? If so, you can do that detection and conditionally add the Threads::Threads dependency.