From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-05-08 06:40:16
----- Original Message -----
> > Yep, with an absolutely fresh, clean checkout:
> > C:\boost-head\tools\build\test>project_test1.py
> > C:\boost-head\tools\build\test>
> 1. I was talking about "startup_v1.py", not "project_test1.py"
Oops. But that works too.
> 2. It really breaks under linux, because the message you expect on the
> 23 of startup_v1.py is generated only on Windows.
Damn, you're right! Fixed.
> > I realized I was changing that, but there was no way to do
> > tests otherwise. And I drove myself crazy trying to use the test
> > I didn't take the time to figure out how to preserve the message. Not
> > fault at all; I think TestCmd is a rat's nest of tangled code.
> Not so tangled I guess.
No, you're right. It's just not well-suited to our needs, and adding
another layer on top of it makes it hard to figure out where to make
> In particular, the fact that 'pass_test' exists is
> quite OK in the context of TestCmd use -- as I understand, another
> automatically runs all the scripts. We'd have to think what we'd like.
...later, though. For now, it works OK.
> > 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.
You wouldn't leave it up to users. Since all of the filesystem
modifications go through the testing class, it would always handle that
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