[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] Workaround for xinclude path bug, fixed in xsltproc 1.1.27?
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.