Beman Dawes wrote:
If our testing was more focused, we could cycle the tests more often too.
Of course, there are more ways to support testing at a higher frequency: 1. Having fewer failing tests. This is obvious but also quite relevant. The number of tests failing isn't small. It would help a lot if those would be fixed. 2. Not compiling/running tests which are expected to fail. We have a mechanism to mark toolsets unsupported for certain libraries. However, this markup is applied _after_ trying to compile/run the tests. If the build system wouldn't even try to run the tests for unsupported toolsets then this would also speed up a test cycle. I'd prefer to have the tests fixed over splitting the tests into two or more subsets being run at different occasions. Regards, m