* The engine can now be built with MinGW-w64 configured with --threads=win32.
This is the case for i686-w64-mingw32-g++ and x86_64-w64-mingw32-g++
distributed with the last versions of Cygwin compatible with Windows XP
(www.crouchingtigerhiddenfruitbat.org/Cygwin/timemachine.html).
The MinGW-w64 toolchains are very powerful, just like their gcc counterparts.
Even the ones with win32 threading model (as opposed to posix threading model),
while not able to use std::thread, can still build-and-use Boost.Thread.
(which, arguably, is more powerful than the Standard counterpart
for example with its support for thread interruption
-- which is less intrusive than the one offered by C++20 std::jthread).
For Windows XP, MinGW-w64 toolchains might be the only ones to support C++11.
Visual C++ has only been supporting C++11 since 2013
(and those versions require-and-often-target newer versions of Windows).
The only part of <thread> we were using was std::thread::hardware_concurrency
(in order to obtain the default value for b2's -j option).
For Windows, we now use dwNumberOfProcessors (in SYSTEM_INFO) and GetSystemInfo.
* Define OSMINOR & OS_HURD on GNU/Hurd
Add a way to identify GNU/Hurd with b2, and also in the Python support.
* Use /proc/self/exe for executable_path on Hurd
Use the Linux compatibility procfs translator to get the full path of
the current executable.
* Define _GNU_SOURCE on any GNU libc-based OS
Make sure to enable GNU features when building on any OS that uses
GNU libc.
When running in Linux containers the POSIX sysconf can return "too many"
cores or cpus. Instead we prefer using Linux specific sched_getaffinity
there.
This implements partial cpu count information on POSIX systems using
`sysconf` call. This should be the fallback for most Unix like systems
if they don't have a more accurate cpu count API.
This adds a `b2::system_info` class to obtain available information on
system we are running in. Currently provides CPU counts.
And currently only implemented for macOS.
