* 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.
* - fix iconv detection for boost.locale on iOS
* clang-darwin doesn't need --start-group
* clang-darwin doesn't need -lrt
* Also need appletv to have the same exception. `appletv` is another Xcode clang related platform that would have the same limitations.
combined-x86-power seems to be completely unused and combined is used only in darwin toolset for Objective-C compilation which seems to be broken for 4 years because it uses gcc.set-fpic-options which was removed in 12decb3ce6.
Boost has three libraries that mentions architecture=combined, I have checked they will not brake after this change.
Removes code duplication in darwin and clang-darwin toolsets.
Removes undocumented `<flags>` from several toolsets, there is documented `<compileflags>` that should be used instead.
* features: Support values for instruction-set feature to support Xilinx ZYNQ.
This adds several values for instruction-set (with extensions) to
support various ARM processors associated with Xilinx ZYNQ processors.
These instruction sets are used in various combinations for bare-metal
or FreeRTOS configurations.
* gcc: Support values for instruction-set feature for Xilinx ZYNQ.
`ar s` seems to be widely supported for a very long time:
- at least binutils 2.10 (June 2000)
- at least Darwin 8.0 (April 2005)
- since FreeBSD 3.0 (October 1998)
Note: Most of other (non-widely used) toolsets do not call `ranlib` and do not call `ar` with `s` flag either. I have no idea if they are correct or not, so I am not touching them here.
Removed empty rules
Removed PCH suffix override (missed in
Fix clang-pch implementation to actually use pch instead of pth. boostorg/build#368)
Removed PCH file explicit removal before creation (should be tested in pch.py test)
Unified <pch>on and <pch>off compilation actions
* clang-linux: space concat via module global variable
* clang-linux: unify pch and non-pch compilation
* clang-linux: remove overridden pch suffix
Missed in #368
* clang-linux: no need to explicitly delete pch file
* remove empty compile.c/c++.pch rules
* 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
Features that are narked as 'free' and 'optional' will now be
ignored when the value specified on the command line is
empty. Hence once can specify `cxxflags=` on the command
line without errors. All current "flags" features are now optional.
fixes#5
Specifying the intel-linux compiler in the path would result in failure
because the path to the compiler would never get detected and hence
the path to the compiler libs would also be missing. This fixes the
issue by explicitly computing the absolute path to the compiler exec
always for both already specified and as found in PATH.
fixes#23
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.
Previously it was needed to include pch header in every source file, but Clang does it automatically making the usage non-uniform. It is also a very noisy process to add pch header to an existing project. Automatic on-demand header inclusion solves both issues.
* pch: msvc source automatic header folder inclusion
* pch test refactoring
* pch test msvc automatic pch source generation
* Include pch header automatically and on-demand
* no more need in gcc pch naming hack
* Versioned Clang automatic configuration
Currently, without annoying `toolset.using` directives in `user-config.jam`, `b2 toolset=clang-xx` silently uses clang++ binary, even if it is a different version than requested. Instead of copycating GCC or reinventing a wheel I have generalized GCC automatic configuration and used it for Clang.
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.
* src/tools/python.jam
(compute-default-paths): When the python include folder without any
suffix does not exist, but one with a m-suffix does, use the latter
Re-introduces functionality that was present in B2, but removed when the "" feature was introduced
Previously, generators could return a property-set as the first item in the result list, this feature removed that. It doesn't seem clear to me that removing this functionality was intentional or necessary to make the feature work. I suspect it was overlooked because the built-in generators did not utilize this functionality that the system supported
