Some latest compilers are rather eager intheir warnings. This can cause
problems with the generated grammar code. Hence avoid such warnings when
compiling the grammar parser.
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.
This change complements the build instructions in the CONTRIBUTING.adoc,
where it is explained to bootstrap the 'stable' engine to
create b2 at the root.
Then, run one of the
two ways to build this be engine.
You can either (a) run b2 b2 at the root,
or (b) run build.sh/bat in src/engine.
Apparently, neither src/engine nor ./src/engine is taken as relative path
by VS Code and leads to task failure:
Executing task: ./build.sh
The terminal process failed to launch: Starting directory (cwd) /src/engine does not exist.
* 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
