Peter Dimov wrote:
Edward Diener wrote:
The regression test matrix appears to be tests by different testers of different libraries, and certainly not of all librariews which may or may not work for a particular compiler which Boost supports in some way. I have rarely been able to make sense of what actually does work with what compiler. Is this a failing of mine to understand the matrix ? Is the matrix really a complete record of all Boost supported compilers and their tests against all libraries which ostensibly support a compiler ?
Yes, the matrix is a complete record of all libraries against all supported compilers. If you look at
http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/user/summary...
for example, you'll see that the program options library is marked "unusable" for VC 6 and 7.0. This means that the library does not support these compilers.
For bind, there's a green 'details' link that leads to
http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/user/bind.ht...
where one can see that the three test failures on VC 6 are marked as "expected failures". Following the first of them to
http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/user/output/...
shows a note at the top that this test failure doesn't render the library unusable.
What if there is no regression test of a particular compiler against a particular library ? Does that mean that the library does not support the compiler, or might it mean that nobody has submitted a test of that library with that compiler ?
The compiler is not supported by Boost.
Thanks for your answers. While the regression tests show what libraries support what compilers, it does so through testing programs. In my case I ran 'bjam "-sTOOLS=msvc"' from the Boost directory for 1.33.1 and received numerous error messages when attempting to build program_options and wave libraries. I think that if a library does not support a particular compiler, as the regression tests show for VC6 and program_options or wave, then an attempt to build libraries which do not support the compiler mentioned on the bjam command line should either skip a build of that particular library or put out a simple error message that the particular library does not support the particular compiler. It should not attempt to build the library at all if that library is clearly not supported for the particular compiler.