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
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.
This archive was generated by hypermail 2.1.7 : 2017-11-11 08:50:40 UTC