This implements the ability for response file "@()" substitution to
dynamically adjust to either expand the content or create the response
file depending on the possible command line length. This should
reduce the create of such response temp files improving build
performance.
Some tests failed because the bootstrap would continue to run even
detecting a problem. This puts in the missing early return statements
in the boost-build builtin rule to get the short circuit on error
like the original Jambase.
This ports the minimal Jambase to native C++. This removes the need for
mkjambase and the Jambase files. To accomplish that it adds C++
utility wrapers around Jam language primitives. Which makes future
similar work much easier.
This adds exclusions for toolsets that use response files for some
commands. Mostly it ignores the generated rsp files.
But also adds a special arg_file value to the MockProgram for future
use for possible content checking.
* Follow-up to removed restriction of pch naming on GCC
* Fix pch path conflict on GCC
gcc-pch-generator rewrites target name to a value derived from a header name
and this cases path conflict if multiple pch are created from the same header.
hello.cpp is duplicated in the test for the same reason but for `exe` target --
`exe hello-afx : hello.cpp ;` uses `hello.o` for object file name.
Do not require pch target to have the same name as the header base name.
The restriction was added in 76d041d7c1 without
a rationale and only for GCC while reworking PCH support for GCC and MSVC.
* Add a warning to running the Boost Build tests about outputting to the console in a configuration jam file.
* Fix the tests if the toolset passed has a version.
Now that the tests work in py2 or p3 we don't set py version in AP. This
allows for dealing with the AP images that don't have a way to set the
py version.
These are some minimal changes to compile with C++. Here begins
the road to rewriting the bjam engine in C++. So far this is only built
and tested with XCode clang on OSX.
With sans-jamroot projects we don't get a missing jamroot error.
Hence we can get other errors, like in this test that fails to find
definitions in the missing jamroot.
* 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.
