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.
local-visibility is intended to be used by libraries or targets that require
a particular visibility mode. It is not propagated to dependencies. It is
equivalent to the previous visibility feature.
The new visibility feature is a composite propagated feature, so it can be
specified by users and higher level targets as a requirement. This feature is
translated to local-visibility.
The new visibility feature can be used to specify default symbol visibility
on compilers and platforms that support it. The default visibility is
global, which matches most compilers' defaults. In gcc documentation it is
called the "default" visibility. Other modes are: protected and hidden.
Use the custom use-packages project rule to load packages as using
import doesn't allow for multiple definitions of packages in the same
project. This allows
* Rework the test case expansion.py to avoid interference from user-config.jam
and toolsets which previously masked this problem. Also add a test case
specifically for this issue.
* Remove the test case for BB60. I have no idea what BB60 is, but the test
case doesn't seem particularly important for the current implementation
given that project requirements are merged into the target requirements
long before conditionals are evaluated.
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.
