From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-05-07 10:28:56
----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
Sent: Tuesday, May 07, 2002 9:55 AM
Subject: Re: [jamboost] My recent changes to load
> 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
> > 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
> > would sometimes look in the boost-build path for the user's file and
> > 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
> > python test_all.py
> 1. I just recieved the following....
> bash-2.05a$ ./startup_v1.py
> Expected STDOUT ==========
> You didn't set BOOST_ROOT
> Actual STDOUT ============
> STDERR ===================
> 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?
Yep, with an absolutely fresh, clean checkout:
> 2. The tests now print nothing in case of success, and you was the first
> objected to this behaviour. Yes, currently. 'pass_test' will exit, but we
> fix it.
I realized I was changing that, but there was no way to do comprehensive
tests otherwise. And I drove myself crazy trying to use the test system, so
I didn't take the time to figure out how to preserve the message. Not your
fault at all; I think TestCmd is a rat's nest of tangled code.
> > Testing is dog-slow; I'm not sure why.
> I can tell you. Because "run_build_system" contains "sleep(1.1)" call.
I thought that might be the culprit.
> Imagine that your tests builds something. Then, a source file is touched
> "run_build_system" is invoked again, to see if something gets rebuild.
> 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.
I had some thoughts:
1. Busywaiting while watching the clock to see when it rolls over: that
would cut the delays in half, or more.
2. Explicitly changing modification times to force rebuilding.
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