David Abrahams wrote:
Okay, here are some issues I think ought to be solved, in no particular order, some (much) more important than others:
David, I'm happy to see you bring up much the same points I mentioned. Here is one I haven't yet got to, and would like to explore a bit further:
* generating XML by parsing the jam log is fragile and prevents the use of multiple build processes (-jN). This one should be almost embarassingly easy to fix.
I think there is more to this than only the ability to run tests in parallel. For example, it would help to robustify the testing harness if the 'test database' could be inspected without actually executing any test. By that I mean the ability to: * See all tests, as part of the test database structure (i.e. their organization into test suites) * See meta data associated with tests, such as - what kind of test - expected outcome, per platform - dependencies, prerequisites, etc. In fact, this wishlist is influenced by the fact that I'm working on QMTest (http://www.codesourcery.com/qmtest), where these aspects are an important part of the overall design. (In fact, I have been trying to convince Vladimir to make it possible to hook bbv2 (at least the part related to testing) up with QMTest in support of the above features. Note also that test report generation and a graphical user interface are an integral part of QMTest.) Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...