Re: [jamboost] My recent changes to load

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-05-07 10:28:56

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
To: <jamboost_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
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....
>
> 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
> /home/ghost/build/boost-cvs/tools/build/test/../jam_src/bin.linuxx86/jam
> -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:

C:\boost-head\tools\build\test>project_test1.py
C:\boost-head\tools\build\test>

> 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
> 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.

> 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.

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.

-Dave