CMakeLists.txt - Hide Unit Test related stuff behind option

[Jogi7819]

Hide required package THREAD behind option to give the consumer the choice to only add the project interface target without any test dependencies.

[Quuxplusone]

The offending line was added by @TBBle in b17b909, and I think I made it obsolete in c5e9751 by removing the one (bad) test file that used anything thread-related. Have you tried just reverting b17b909 and seeing if anything breaks?

[Jogi7819]

Will check that today and give a feedback. But still if that commit would be fine I would suggest to hide all test related stuff behind an option that can be set by a top-level project.

[Jogi7819]

The offending line was added by @TBBle in b17b909, and I think I made it obsolete in c5e9751 by removing the one (bad) test file that used anything thread-related. Have you tried just reverting b17b909 and seeing if anything breaks?

You are right the package is not required anymore and can be removed. Done in my PR.

[Quuxplusone]

Seems harmless to me, but also IMHO unnecessary. I don't know much about how we expect this library to be consumed. Does it really make sense for someone to want to consume this library without running its tests? And if they did, would they really do that by wholesale-importing the CMakeLists.txt that we wrote, instead of by just cutting and pasting the single .h file they were interested in?

[Quuxplusone]

Could you uncuddle this parenthesis again, so that git show -b will have one fewer gratuitous diff?

[Jogi7819]

Done

[Jogi7819]

Seems harmless to me, but also IMHO unnecessary. I don't know much about how we expect this library to be consumed. Does it really make sense for someone to want to consume this library without running its tests? And if they did, would they really do that by wholesale-importing the CMakeLists.txt that we wrote, instead of by just cutting and pasting the single .h file they were interested in?

One aim of modern cmake is to provide everything by target and target specific. Means to me: includes, flags, definitions, etc.
Also I guess to keep external dependencies as small you can, so why adding test related stuff (includes the target itself) if you are not a third-party lib developer. The THREAD dependency is a good example here. It has been required at some point to build the test but it was never required to use the lib itself.