mesonbuild
Query the threading model from dependency('threads')
Fixes: #553
This may not be a full fix for 553, but it at least gives the user the ability to see what threading model meson has decided to use and react accordingly.
Fixed a couple more typos (as well as the one mensida caught). Also made the test more accurate (fixed mingw)
Should this be like an introspection thing because as a Meson build user this seems strange just to query the threading dependency just to see what type it is. If you think about it kinda adds some none constant functionality.
No, this isn't an introspection thing. If you write code that calls pthread_init, you need the threading implementation to be pthreads. If your code calls CreateThread you need to have win32 threads.
It sounds like @jpakkane is good to go on the direction @dcbaker originally took this PR?
To bring this up also here, exposing the chosen threading API makes this slightly less awful but it remains problematic on all platforms with multiple threading APIs (e.g modern illumos supports all three of ISO C11 threads, pthreads and Solaris/illumos threads) as it doesn’t allow a user to specify which threading API they even can work with. Meaning, a programs actual threading functionality might end up disabled, eventhough the necessary API is supported just because Meson preferred to select a different API.
Actually being able to chose an explicit API as requested in #553, e.g. via a flavour option in dependency('threads') as proposed in the comments of #13124, is the only way to actually make this work properly. With an explicitly requested API model, it’s not necessary to recheck what was chosen. Reading back the chosen API will then at most be useful for an auto mode, but it is hard to imagine a scenario where someone is fine with literally any abstract, undefined threading capability but needs to know which. I doubt most software is equipped to deal with illumos threading API and even the SciPy example from above would rather prefer to explicitly check for just pthread or all the APIs BLAS supports.
The most probable use for auto is (as was brought up before here) when using C++’s std::thread, which just needs something to back it and what powers it is opaque to the user. But even this would be better served by explicitly requesting flavour: 'cpp' or similar.
But if exposing the chosen API is the only thing people can agree on atm, it at least makes this a bit less awful to work with, so better than nothing.
