Re: [docbook-apps] Workaround for xinclude path bug, fixed in xsltproc 1.1.27?

[Warren Young <warren@etr-usa.com>]

Accidentally took this off-list:

On 9/11/2014 14:49, Bob Stayton wrote:
> There is nothing the XSL process can do to correct this problem, as the
> resolved file does not have the information necessary to locate qux.txt.

Though I posted this to the DocBook list, I wasn't expecting a fix to 
the stylesheets to work around this xsltproc bug.  I was just hoping 
that there were enough people here using xsltproc that I might find 
someone who had run across this years ago, before it got fixed, and 
worked around it in some clever way.

The question would be more on-topic on the libxslt mailing list, but 
they'd probably just tell me to upgrade.

> If those links are autogenerated,

This is static user documentation for an open source library.  The 
generated files are really just preprocessed, to add or remove a few 
things; they are not fully generated.

If you build the docs in-tree (./configure && make), the generated files 
and static DocBook source files end up in the same directory, so there 
is no problem.

The problem comes when you use the build system's ability to build 
outside the source code tree.  In that case, you end up with about half 
the files -- the ones lightly preprocessed -- in the build tree and the 
rest left behind in the source tree.  You can use xsltproc --path 
feature to point to both directories to cope with this, unless you're 
using an old xsltproc and you have an XInclude in a build tree file that 
refers to a file in the source tree, which in turn XIncludes a file that 
lives in the build tree.  Older xsltprocs can't follow that double 
indirection.

I think I'm just going to say the minimum version is 1.1.27.  That will 
give me the excuse I need to move to DocBook 5.  I couldn't do it before 
because I support some really old systems, and I only want to support 
the DocBook XSL files that come with the OS.