* 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.
* Clang: Use --version instead of -dumpversion
Fixes issue when Clang 8 and below determined as 4.2.1 version.
* Bootstrap and test with versioned toolset
Eliminates need to manual configure toolsets via `user-config.jam` for testing, and allows to pass to `bootstrap.sh` the same toolset string as you would to B2 invocation what eliminates need to specify a custom exec via `--cxx=`.
This adds default/fallback logic to determine the b2 exec absolute path
as possible. It uses the arg0 and current dir or path to construct the
liekliest path.
fixes#25
Some platforms, like AIX, when building with gcc need `-pthread` option to enable std thread support. This adds an alternate check with that option as fallback to plain gcc compile.
Surround the `CXX` path with double quotes to support spaces in the path.
Otherwise if the `CXX` variable is set to a path containing spaces like
```
C:/Program Files (x86)/Microsoft Visual Studio/2017/BuildTools/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe
```
the following error message is printed:
```
'C:/Program' is not recognized as an internal or external command,
operable program or batch file.
```
Using pygments.rb fails on Ruby3 because of missing class create
methods. Which makes using the same script for ruby2 and ruby3
a problem. We aren't using pygments currently anyway, so
disable it for now.
There was a systemic error of using ":=" instead of ":-" var expansion
that caused all kinds of problems. Replacing all the instances to be
correct fixed them. But also brought to light other problems. The
changes include fixing the intel detection to no leak and persist it's
setup. And to also support setup script generally if required.
Fixes#705
CXX was previously only used to replace the exec part of the compiler
commands. This change restores that aspect. It also makes the toolset
checks short circuit so that we do get the best toolset and command
detected.
This rewrites the build.sh to remove duplication of base compiler
command to combine checking the command and specifying it.
Which allows for only detecting valid working commands, and
hence toolsets. This also adds the new Intel oneAPI compiler.
