on Sun Aug 05 2007, David Abrahams <dave-AT-boost-consulting.com> wrote:
on Sun Aug 05 2007, "Timothy M. Shead" <tshead-AT-k-3d.com> wrote:
David Abrahams wrote:
However, output serialization is only important because both Boost's process_jam_log and ctest/dart currently use a parse-the-build-log strategy to assemble the test results. This approach is hopelessly fragile in my opinion. Instead, each build step in a test should generate an additional target that contains the fragment of XML pertaining to that test, and the complete result should be an XML file that is the catenation of all the fragments. Rene is working on that feature for BBv2. I don't expect it would take more than a couple of days to add this feature to either build system, so the advantage of serialization may be easily neutralized.
There may be some semantics here that I'm missing, but I think ctest is already doing exactly what you describe:
Bill Hoffman (of Kitware) himself told me that parallel builds don't work with ctest because of output interleaving issues. Was he mistaken?
Bill just sent me this clarification privately: they can handle parallel *builds* (with some caveats I didn't really understand that made it sound somewhat unreliable), just not parallel (runtime) *tests*. Why these two kinds of action should be treated so differently is a bit of a mystery to me. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com