cmake: always use pthread outside of MSVC

[illwieckz]

Always use pthread outside of MSVC.

After enabling it unconditionally I seen no build issue with Linux (GCC and Clang), macOS (AppleClang), FreeBSD (Clang), MinGW, PNaCl.

Also, CMake reported the flags to be supported in all cases, so we may make the flags mandatory.

It happens that the linker flag was lost in translation in #1997:

• cmake: unify GCC, Clang and PNaCl compiler configuration #1197

So I re-added it. It being missing did not bring any issue into all our builds (either on my end, either in our CI), but this is better like this I guess.

[slipher]

I don't think we should add the flag except where it is actually needed.

[illwieckz]

How do we know it's actually needed? Isn't just using threads makes it needed?

[slipher]

Normally you don't have to request linking to pthreads unless you directly use the pthread API, e.g. pthread_create. For example, with MinGW, you do need -pthread if you explicitly use the pthread API. But you don't if you use std::thread: that's expected to be provided by the C++ standard library. Just some Linux toolchains are an aberration where you have to pass -pthread despite not having used its API.

In the non-Windows engine, we do call pthread_sigmask. So it would be logical to add the flag to the MacOS engine build (but not gamelogic), even though it apparently builds without it.

[illwieckz]

So, how do we know if FreeBSD requires that flag?

[slipher]

Well if you want, you can test whether it builds with -pthread. Or if not, just toss in the flag on FreeBSD too to be safe.

[illwieckz]

As said in first post I tested the build with this flag on both Linux, FreeBSD, macOS and MinGW (and even PNaCl). In all cases it builds, and the flag is accepted for both compilation and linking.

[slipher]

Oops typo, I meant you can test whether it builds WITHOUT -pthread.

FreeBSD is the same situation like Mac, if you base it on whether the pthread API is actually used engine would need it but not gamelogic.