From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-08-19 05:11:51
John Maddock wrote:
> Rene Rivera wrote:
>> Taking this to the docs list...
>> John Maddock wrote:
>>> Doug: is there server space we can put this on?
>> I brought the possible need for a documentation building server with
>> the moderators last week. Which includes you John ;-)
> Um, so you did, now where did I leave that brain of mine....
>> I mentioned
>> setting up a buildbot for this. In particular it would be possible to
>> have a doc building slave which others can ask to build docs with
>> (from the buildbot web interface). If the doc builder is the OSL
>> machine the docs can be made available through beta.boost.org.
>>> The tricky part I suspect
>>> is getting links to images to function correctly, we may need some
>>> adjustments to BBv2 before we can make full use of this?
>> Which images?
> Here's the outstanding issue: suppose I have a quickbook file that
> references some png's (or whatever):
> The path ../ is set up so that it's relative to where the html docs are
> generated (in a html/ subdirectory), but FO files and PDF's currently end
> in a long mangled path under bin.v2/. So... neither admonishment
> graphics, nor referenced image files are found, unless you manually move
> them to where
> the FO processor is looking for them. Not fun :-(
I think the idea of "setting paths ... so that it's relative to
where the html docs are generated" is wrong -- if you add "--build-dir"
option to bjam, all your paths will be wrong, even with HTML.
Is there any option to quickbook/boostbook/docbook to specify
search paths for images?
> So the question is how do we get the server to "work". If we instruct it
> to build from a Jamfile in SVN, then IMO we need to fix up BBv2 so that
> .fo and .pdf files get placed in a sub-directory (called pdf?) just like
> HTML does,
> and then hopefully external image files will get automatically found. In
> fact I believe this is the "right thing to do" anyway, as it eases local
Uh, well, removing toolset and other things from build path will be easy.
The problem is that now HTML generation is weird -- it generates
to $srcdir/html and unconditionally putting thigns to srcdir is bad.
So I'd suppose we need to fix that first, and then again, relative paths
to images won't work.
> Alternatively, the easiest option for the server setup might be to only
> accepts self-contained .fo files with all the images embedded inside it.
> Unfortunately I don't believe that XSLT processing can automatically embed
> externally referenced image files, so that would need a post-processing
> step or something.
I have no idea/comment on this alternative.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk