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

Subject: Re: [Boost-docs] Making Boost Doc builds more robust
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2008-12-02 03:19:38

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.

In that order of preference. Obviously there are many details.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail