Re: [jamboost] My recent changes to load

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-05-08 02:40:53

David Abrahams wrote:

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

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

Well....
1. I was talking about "startup_v1.py", not "project_test1.py"
2. It really breaks under linux, because the message you expect on the line 
23 of startup_v1.py is generated only on Windows.

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

Not so tangled I guess. In particular, the fact that 'pass_test' exists is 
quite OK in the context of TestCmd use -- as I understand, another program 
automatically runs all the scripts. We'd have to think what we'd like.

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

I think this is good idea.

> 2. Explicitly changing modification times to force rebuilding.

Too troublesome for me. Users will be forgetting to do it. 

- Volodya