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.
* 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.
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.
Currently the same data is read twice.
The first time a buffer is filled by `PeekNamedPipe` and second time it is
overwritten with the same content by `ReadFile`.
It looks like the OS has the internal buffer around 4KB and with any buffer
over this size `read_pipe` will end the reading loop after first try despite
that reading a pipe may pump a new data and it can be read immediately.
This is allocating space for `nel` objects of type `ITEM*` so it should use `sizeof(ITEM*)` not `sizeof(ITEM**)`.
In practice the values are the same, but using the correct type is better anyway, and now matches the same calculation in the `memset` call in the following statement.
While building boost, I noticed that jam0 and bjam used 100% of a CPU.
Strace showed that they were calling poll with a zero timeout in a loop.
This is because:
- the logic in exec_wait() initializes select_timeout to globs.timeout
- globs.timeout is zero when no action timeout is specified
- poll interprets a zero timeout as "return immediately" rather than
"wait indefinitely".
Fix this by passing -1 to poll when globs.timeout is zero.
* The new scanner is currently disabled and only issues a warning
for tokens that would be lexed differently.
* Special case a few common uses of ':', to limit breakage to
a manageable level.
* Remove the horribly outdated Jambase code inherited from Perforce Jam
* Update all of Boost.Build to work in the presence of the new lexer.
- Add missing WINVER=0x0501 and _WIN32_WINNT=0x0501 to config_toolset.bat
- Add needed -D_WIN32_WINNT=0x0501 for vc7 to fix unresolved symbols
- Added alternatives to va_copy and vsnprintf in debugger.c
- Add missing fix from previous patch in strings.c
