Re: [boost] Release Tools Analysis Part I: Build systems

From: David Abrahams (dave_at_[hidden])
Date: 2007-08-08 10:23:58

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