From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-10 21:26:18
----- Original Message -----
From: "Beman Dawes" <bdawes_at_[hidden]>
> The effect we want is that there is "library-build" test, and that would
> the one we report as failing. (If it fails, there is no point in even
> reporting the tests dependent on that library, but let's ignore that for
> How about invoking Jam multiple times?
> invoke jam to build library X
> add the results to the status table
> repeat for libraries Y, Z, ...
> invoke jam to run tests
> add those results to the status table
Try it and see if it works, I guess.
> Note that <lib> dependencies have to be removed from the current
> boost-root/status/Jamfile, since we just want the tests to fail if a
> library isn't present. We don't want to try to build the library while
> processing the status/Jamfile.
How do you propose to test the regex library, for example, if you don't
arrange for it to be built?
Or, how do you propose to arrange for it to be built and linked into the
> This seems pretty simple, or am I missing something?
one of us is...
> I'll have to look at the normal library build output to see if it is
> possible to tell if it succeeded or not, but if necessary I can hand
> some C++ code that looks for the lib files.
Not sure what you're talking about. Which lib files are you planning to
> >It's clear to me that we need to look at what features a build system
> >in order to support testing, and we'll need to modify Jam accordingly.
> >Unfortunately, I don't have the time to do that right now, much less to
> >it alone. Because it's clear that some momentum is building behind the
> >testing system, I'd be willing to help someone else think it through.
> >it's not too complicated, we can try to implement it (though this is
> >probably the hairiest part of the Jam source).
> Hopefully, the scheme above won't require a lot of changes.
I don't understand it, but so far it doesn't sound like I need to do
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