John Maddock wrote:
Vladimir Prus wrote:
Here's the outstanding issue: suppose I have a quickbook file that references some png's (or whatever):
[$../graphs/graph1.png]
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 up 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?
Yes there is, it's the image.src.path option.
I haven't tried it though, because the path specified in the <xsl:param> Jamfile option requires a trailing / in the name,
Truly weird interface, I would say.
but bjam "helpfully" strips the slash from filenames, so specifying paths to external elements that way is currently broken anyway.
In any case, how would we set a relative URL from what is currently an "unmentionable" path where the pdf docs are built to the image location? Or even an absolute path for that matter - is $(BOOST_ROOT) generally available in a Jamfile these days?
It is, as a quick look at $svn_trunk/Jamroot will reveal.
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 building.
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.
I can only speak for myself here: but personally I really like where the html is placed now, and I'd like pdf's etc to do the same.
So, the requirement that user should be able to build boost from a readonly medium without copying is lifted?
Frankly I'd be pretty unhappy if the location changed, and coincidently, it would break quite a bit of Boost's current docs.
What's going to break, specifically? Note that even now, the doc location is different when building full boost docs, and when building docs for just a single library. - Volodya