Currently the size of reading buffer is 16KiB while the the pipe buffer is of
system default size which seems to be 8KiB on Win7. Because of this the half of
the reading buffer is never used.
Also, recent Windows updates with Meltdown mitigation made syscalls more
expensive, and increasing the buffer size will lower the syscalls count.
Add support for a common set of sanitizers supported by both
gcc and clang:
- thread
- address
- undefined
Signed-off-by: Damian Jarek <damian.jarek93@gmail.com>
* If the user provided a command, don't try to use the autodetected command
as well. The fixes errors caused by passing too many arguments.
* If the user provided a command, but not a version, try to detect the
version from the command. This code already existed, but was useless
because it was run too late. It also failed for 14.1+ because of
incorrect escaping for MATCH.
* When handling duplicate initialization, make sure that we compare
the original user options to the new user options. Previously, we
compated the new user options to the auto-detected command which
makes no sense at all.
* If the user specified a command, always search for it in PATH, instead
of also searching version specific locations.
- Fix copy/paste in the environmental variables.
- If vswhere exists, but doesn't find a given version, exit
detection early and don't fall back on checking the environment.
- Clean up hackish vswhere handling.
* Fix "bootstrap.bat borland" failing to find label "Test_Path"
If an override toolset is given in the `bootstrap.bat` command-line,
`bootstrap.bat` -> `src/engine/build.bat` bypasses loading
`src/engine/guess_toolset.bat` entirely. Later on the call to
`Test_Path` from `build.bat` -> `config_toolset.bat` fails to find that
label.
Fix this by making a new parameterized entry-point `test_path` inside
`guess_toolset.bat` for this caller in `config_toolset.bat`.
Fixes: #382.
* Handle spaces in C++Builder toolchain path
Nowadays a default installation goes into %PROGRAMFILES%, e.g.
"C:\Program Files (x86)\Embarcadero\Studio\20.0\Bin".
* Add "-Nd" before "/D"-options for bcc32.exe
The preprocessor of the old Borland/C++Builder compiler (bcc32.exe) by
default does not accept preprocessor statements of the form:
#if SYMBOL_NAME
where `SYMBOL_NAME` was `#define`-ed without a value. It insists on the
`#if defined(SYMBOL_NAME)` or `#ifdef SYMBOL_NAME` forms (emitting error
E2188 "expression syntax"). The workaround is to specify the `-Nd`
option before the offending `/D` options, which effectively provides a
value of "1" to the symbols being #define-ed. Apply this workaround in
the recipes of `bjam` and `b2` to satisfy the preprocessor.
The alternative here would be to migrate to the Clang-based (and much
more standard-compliant) bcc32c.exe, but that would be a more involved
change.
* Separate :Guess_Yacc logic from :Guess_Toolset in build.bat
This was an existing benign issue introduced in 00c2358, but it became
apparent after 9339693.
This avoids warnings=all and warnings-as-errors=on causing irreprerable
damage to humans. And makes it possible to have more warnings without
destorying the universe.
fixes#394
When running build.sh with the cross-cc toolset, it uses the native
compiler settings found in the BUILD_CC, BUILD_CFLAGS, and
BUILD_LDFLAGS environment variables to create executables to run on
the build system. It then sets the toolset to cc so that the
cross-compilers given as CC etc. are propagated to subprocesses.
This ensures both that the build system can build and execute its
required programs and that final executables are cross-compiled for
the target architecture.
The bug happens because exec_check replaces the shell inside
the command structure, but make1cmds retains a reference to
the old shell. The bug appears when all of the following are true:
- The action is piecemeal
- b2 is running on Windows
- SHELL is %
- The action contains elements that require a shell
- The action is split into multiple commands
In particular, this applies for gcc.archive with a large
number of object files.
Instead of attempting to reuse the same shell, we make
a new copy in every iteration of the loop. The shell
and target lists are usually short and the cost of copying
them is insignificant compared to the other work done by the loop.
In addition, the optimization is rarely triggered because
piecemeal actions that require splitting are relatively rare.
Rene Rivera