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

Subject: Re: [Boost-docs] Making Boost Doc builds more robust
From: John Maddock (john_at_[hidden])
Date: 2008-12-02 12:16:33

Daniel James wrote:
>> 2008/12/2 John Maddock <john_at_[hidden]>:
>>>
>>> Well... there appears to be something wrong with the Jamfile,
>>> because I get:
>>>
>>> '"..\..\..\bin.v2\tools\quickbook\test\msvc-8.0\debug\link-static\threading-multi\line-compare-tool.exe"'
>>> is not recognized as an internal or external command, operable
>>> program or batch file.
>>
>> I get the same. The executable gets built, but it gets deleted at the
>> end of each test. Boost build seems to think it's a temporary file.

Ah, it gets deleted by the "**passed**" rule in testing.jam, is there any 
way we can override that rule so it doesn't delete the .exe?

>>> One other thing I've noticed is that quickbook doesn't always exit
>>> with an error code if the markup is invalid - things I particularly
>>> noticed were xinclude/include/import not failing if the specified
>>> file name is invalid.
>>
>> This was the problem was had in the last release. Some of the
>> documentation wasn't included but nobody noticed until the last
>> minute because the build succeeded.
>>
>> There's already a ticket:
>> https://svn.boost.org/trac/boost/ticket/1399
>>
>> Which is another problem - everyone is busy with other things.

Nod.

However, if we can fix the testing Jamfile, and add it to the main 
regression tests, it will be a lot easier to add new test cases.

>> FWIW, on linux the documentation build has been very stable for me
>> (apart from the recent quickbook bug). The issue with building the
>> accumulators documentation on windows has been fixed

Sorry, but does the build fail if latex, ps etc are not present in the path?

>> The only remaining issue that I'm aware of is that quickbook doesn't
>> work with some cygwin paths. I think it's only for paths that begin
>> with '/cygdrive' (so it might not happen if you checkout boost inside
>> your cygwin home directory) and that it's not a new bug but it became
>> a problem in the last release because boost build started using
>> absolute paths.

I suspect that mixing cygwin and win32 builds of tools will always be a dead 
loss.  Using all Win32 builds throughout seems to work OK though.

John.