Re: Fw: [boost] Boost.Build problem?

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-08-21 12:49:36

--- In jamboost_at_y..., "David Abrahams" <dave_at_b...> wrote:
> 
> From: "bill_kempf" <williamkempf_at_h...>
> 
> > --- In jamboost_at_y..., "David Abrahams" <dave_at_b...> wrote:
> > > Hi Bill,
> > >
> > > I just checked in some changes to your Jamfile which should 
correct
> > > everything.
> > > Please try a clean rebuild.
> >
> > OK, everything compiles, but nothing runs! This is now true no
> > matter what TOOLS I use!
> 
> Weird. It seemed to work for me.
> Are you sure nothing runs?
> Just tried it again. The lines labelled "capture-run-output" are 
the ones
> invoking your tests.

Ahh... I'm used to seeing the run in the actual output. Having to 
inspect a text file to determine if the tests failed is a Bad Thing 
as well.

> > > The unit-test rule is really not very sophisticated: it makes
> > the .exe
> > > target dependent on a successful run. Of course that means 
that it
> > gets
> > > removed if the run fails.
> >
> > Which is precisely what I want. :(
> 
> No you don't. If the run fails, you shouldn't have to re-link the
> executable the next time you try to build.

If the run fails, I'll be fixing code that will hopefully make it 
not fail the next time around, so a re-link is almost certainly 
going to be necessary the next time I try to build any way.

I guess what I want is a cross between the behavior of "run" 
and "unit-test". I want the output to be visible during bjam 
invocation (though it can still be captured in a file as well), and 
if the run fails I want the next bjam invocation to still run the 
executable (linking I suppose could be considered bad and can be 
removed). Further, failed runs should be reported as failed target 
updates by bjam.

In any event, I don't see how the run targets are going to be useful 
to me. The results are just too difficult to inspect for test 
failures. Failed runs aren't reported by the bjam invocation at 
all, let alone which specific tests failed. So I'd have to inspect 
all 96 output files, each buried in a deep tree structure, just to 
know if the tests passed or failed.

> > I don't understand why this is a problem only with the gcc 
toolset.
> > The msvc, vc7 and borland toolsets all work flawlessly with unit-
> > test, and they should all be doing the same thing in this case, 
no?
> 
> They don't need the JAMSHELL workaround for the link step since 
they can
> use command files.

That makes sense. Unfortunately, that makes it sound like I'm not 
going to find an acceptable solution to my problem in a short time 
frame, huh?

Bill Kempf