From: David Abrahams (dave_at_[hidden])
Date: 2007-10-16 15:09:26
on Mon Oct 08 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
> I think the whole idea of providing the test matrix as a guide to
> which compilers work with which libraries is misguided.
I agree. The test matrix as it currently stands isn't even really
useful to developers, though that's a different issue (there's just
too much information there).
> Installation procedure should include a local test procedure
> which builds the test matrix for the user's local environment.
> This was my motivation for "library_status" executable and
> script. This would give a couple of advantages over the current
> a) Users would be able to verify that the installation is correct.
Yeah, one of our problems currently is that our testing system doesn't
install the libraries and then test the libraries as installed.
CTest works that way. Our current tools could theoretically also be
changed to do that.
> b) Users would have a test matrix which is applicable to their
> particular environment. This can be referred to in the future
> to verify that that the boost facilities that they want to work
> or don't work in thier environment.
> c) I would permit more testing - release as well as debug, static
> as well as shared libraries, etc.
> d) It would make support of user problems much easier. If
> someone says X in library Y doesn't work, some who want's
> to help can respond "what are the results of test X on library Y".
> e) someone was really ambitious he could arrange to have
> the test results shipped to a central location for display - to
> maintain a more complete test matrix. But this is just
> a refinement not essential.
I agree that something along those lines is a good approach. However,
I do think that Boost needs to make claims about what will work that
are useful to a large proportion of our users, so they can decide
whether to make an investment without building and running tests
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk