From: Robert Ramey (ramey_at_[hidden])
Date: 2007-10-08 17:20:15
I think the whole idea of providing the test matrix as a guide to
which compilers work with which libraries is misguided.
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.
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.
Jeff Garland wrote:
> Edward Diener wrote:
>> From an end user's perspective I think it is really important, for a
>> given release and library of Boost, to know whether or not a
>> particular compiler is supposed to work for a particular library.
>> The regression tests do not, unfortunately, always give the end user
>> that information. While I understand the concern for getting out
>> timely releases of Boost which are guaranteed to support a subset of
>> highly conformant compilers, this way of doing things will only
>> make it even more difficult for end-users of those compilers which
>> are not part of that subset to determine whether the latest release
>> of a particular Boost library is supported when using their compiler.
> While I agree this might make understanding the status a tiny bit
> harder, it's worth it for the majority of users to actually have
> access to the new libraries that have been accepted into boost --
> even if regression status is a bit harder to understand. asio was
> reviewed in Jan of 2006 and if we don't take some radical steps it
> won't be in a Boost release in 2007 -- almost 2 years later -- the
> current state of affairs is simply unacceptable.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk