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

From: David Abrahams (dave_at_[hidden])
Date: 2002-08-21 17:54:32

From: "bill_kempf" <williamkempf_at_[hidden]>

> > You're right. "clean" is failing to remove some of the testing
> residue
> > files. I just fixed that, I think.
>
> I just did a cvs update and still see the same results. Did you
> check the fix in?

Yes.

cvs log tools/build/testing.jam

> > > It would be nice to have a distclean
> > > that clobbered the directory no matter what.
> >
> > Wouldn't it?
> >
> > > 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.
> >
> > Sure would!
>
> Any chance these are in the plans for V2? Please? ;)

Relatively speaking, they're so easy that they're not worth planning for.
You could even do them for v1 without too much trouble.

> > > 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.
> >
> > No it doesn't. "test" is an abstract target like "all" or "exe",
> which
> > depends on a whole bunch of actual targets, namely all of the test
> results.
>
> OK, that makes sense.

It still makes no sense to me why only one test is being built.

> But does this mean there's no way to specify
> only certain tests be added/run from the command line? For
> instance, let's say I just want to run test_condition.cpp.

bjam -sTOOLS=... test_condition

However, there's clearly a bug somewhere in the interaction of the test
tools with the <template> feature. The issue is that declare-local-target
is supposed to return the list of the target files for the target it
builds. However it appears to be returning results of the form
(<some-grist>test_base.test)*, where test_base is the name of a template.

> > I've enclosed a listing of the commands executed when I build
> test, then
> > clean, then test again.
>
> Enclosed it where?

I sent it in separate mail to you. Re-enclosed here.

> OK, I've looked there, and the documentation is minimal. To really
> understand everything that's going on you have to read the Jam code,
> which I can only half follow. Any chance anyone could work on
> documenting these target types in the bjam documentation?

Probably not until we get a better idea of what /should/ be happening.
Beman seems pretty dissatisfied with the current scheme. I'm trying to get
people to talk about what a testing system needs to do so that I can try to
make it do that.

-----------------------------------------------------------
David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com

 ------=_NextPart_000_1116_01C24944.2FCAAA50 Content-Type: application/x-zip-compressed;
name="tmp.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="tmp.zip"

[Attachment content not displayed.] ------=_NextPart_000_1116_01C24944.2FCAAA50--