Re: [Boost-docs] Making Boost Doc builds more robust

Subject: Re: [Boost-docs] Making Boost Doc builds more robust
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2008-12-02 07:38:11

Rene Rivera wrote:

> Joel de Guzman wrote:
>> Beman Dawes wrote:
>>> Right now the Boost documentation build is a serious problem from the
>>> standpoint of release management.
>>>
>>> There is no way to tell if doc builds are working other than asking
>>> people to look at the results. This prevents automatic notification if
>>> the build process breaks. It seems to me the first step in making doc
>>> builds more robust is adding a boost-root/doc/test directory with a
>>> Jamfile and test cases that can be used to debug the problems.
>>>
>>> Documentation builds only work for me on Linux. Builds on Windows work
>>> for Eric, IIUC, but not for me.
> 
> Windows and Linux builds, at least for the bjam docs, work for me.
> 
>>> This prevents me from running
>>> automatic daily release branch builds. It would be a lot easier to
>>> debug this problem if we had a test setup.
>>>
>>> Once we have a test setup that can detect if an error occurs, we can
>>> work on ensuring that error messages (1) say what probem occurred and
>>> (2) say what to do to correct the problem.
>> 
>> FWIW, Quickbook already has some tests in there, but they are not
>> hooked up and I only occasionally get to run the tests and only on
>> Windows. Yes, it would be great if it becomes part of a test setup.
> 
> And quickbook and docs are not the only tools we need to test. And I
> mentioned in a BB post that we really want to have tool testing happen
> in an independent process than the regular testing, i.e. have separate
> results, as it needs to detect breaking changes before they impact the
> main testing. The options for doing this I can think of are:
> 
> a) Find an off the shelf testing and results solution. The key here is
> that we don't have the high level of result reporting as the mainline
> testing so we may be able to find something suitable.
> 
> b) Extend regression.py to modally do a tools test suite. And have it
> directly generate HTML reports.
> 
> c) Like (b) but generate XML that can be fed into the XSLT report
> generation.

FWIW, I'm working on running Boost.Build tests in regression.py, which will
make them appear in the main matrix. This seems perfectly fine for me, as
the tests generally run fast enough.

- Volodya