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

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-08-21 16:13:38

--- In jamboost_at_y..., "David Abrahams" <dave_at_b...> wrote:
> From: "bill_kempf" <williamkempf_at_h...>

I replied once, but I think Yahoo barfed on it. So I appologize if 
we get multiple replies here.

> > What you describe as the actual behavior, and what I see when I 
use
> > the -a option (or do a clean first), are in fact quite usable.
> > However, I'm experiencing several issues, some of which were the
> > result of the confusion here. Let me describe them.
> >
> > Just modifying a test to produce an error and then invoking:
> >
> > bjam -sTOOLS=vc7
> >
> > appeared to run, with out any indication of failed targets.
> 
> None whatsoever? Please give me instructions for reproducing this.

None whatsoever. However, your comment below about specifying 
the "test" target explains it.

> > Deleting the bin directory entirely results in the same behavior:
> > i.e. everything compiles, no failed targets are reported, and
> > there's no "capture-run-output" in the output.
> >
> > I can't explain any of that behavior.
> 
> Me neither. Isn't that the same as what happens when you do a 
clean first?
> BTW, are you explicitly requesting the "test" target? Tests don't 
run as a
> result of building "all"

Not precisely. It only cleans up files/directories that it creates 
and thinks should be cleaned. If any files are left over the 
directories aren't removed. It would be nice to have a distclean 
that clobbered the directory no matter what.

Also, it appears the output files from "run" aren't cleaned. So bin 
isn't deleted any more in any event.

Further, and this is the one I often find frustrating, clean also 
invokes clean on dependent projects. So cleaning 
$BOOST/libs/thread/test will also clean $BOOST/libs/thread/build and 
$BOOST/libs/test/build. It would be nice to have a target that only 
cleaned the current project, leaving dependent targets alone.

Now that I'm done with asking for further enhancements, let's get 
back to the subject ;).

> > Another thing I notice is that only one target (including it's 4
> > variants) is being built, and is named test_base.test. It 
appears
> > that this is the target based on test_thread.cpp. The other 5
> > targets aren't built or run at all.
> 
> Perhaps because they're up-to-date?

bjam -sTOOLS=vc7 clean
bjam -sTOOLS=vc7 test

Produces the following tree:

bin
test_base.test
debug
runtime-link-dynamic
threading-multi
runtime-link-static
threading-multi
release
runtime-link-dynamic
threading-multi
runtime-link-static
threading-multi

Since I specified only one target, "test", it makes sense that only 
one was built. What's not as obvious is why the target produced 
is "test_base.test", why the target for test_thread.cpp is this 
target, or what target name would be valid for, say, the target that 
builds test_condition.cpp. Seems like a case where I should RTFM, 
but it doesn't appear that the "run" target is documented. Sorry to 
be a pest about this, but I need some more enlightenment.

Bill Kempf