From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-05-07 09:55:48
David Abrahams wrote:
> No time to explain everything right now, but I've just gotten through
> rationalizing the load behavior a bit. In particular, the old one used to
> demand that the user have a boost-build.jam, which would then load the
> system's boost-build.jam, which caused all kinds of confusion because it
> would sometimes look in the boost-build path for the user's file and find
> the system's file instead. The system's file is aptly renamed to
> bootstrap.jam. I added tests to the test directory. Run all tests now with
> python test_all.py
1. I just recieved the following....
Expected STDOUT ==========
You didn't set BOOST_ROOT
Actual STDOUT ============
Jamfile: No such file or directory
FAILED test of
-sBOOST_BUILD_PATH= -d0 --debug --quiet
at line 156 of ./BoostBuild.py (run_build_system)
from line 22 of ./startup_v1.py
Does this test work for you after a fresh checkout?
2. The tests now print nothing in case of success, and you was the first who
objected to this behaviour. Yes, currently. 'pass_test' will exit, but we can
> Testing is dog-slow; I'm not sure why.
I can tell you. Because "run_build_system" contains "sleep(1.1)" call. Why?
Imagine that your tests builds something. Then, a source file is touched and
"run_build_system" is invoked again, to see if something gets rebuild. But
often, the time to build the entire test program is less than 1 sec, to
"touch" just changes nothing. I find that taking care of this in
"run_build_system" is better than relying on user.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk