docbook-apps

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.

Hello,

Am 12.09.2014 um 00:19 schrieb Warren Young:

> 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.


Have you thought about using an XML catalog file?

I once had a problem, where some files where not located, where xsltproc was locking form them. I was able to use a catalog to supply a 'corrected' path for those files.

I did not use xinclude, so I don't know, wether catalogs are used to locate xindluded files.

73, Mario
--
Mario Klebsch
mario@klebsch.de
PGP key: http://www.klebsch.de/public.key
PGP fingerprint: C906 D123 2361 2164 218F 1B52 6258 1853 300B 6C18

On 9/15/2014 14:16, Mario Klebsch wrote:
>
> Have you thought about using an XML catalog file?

The solution I settled on is to disable the user manual build rule when
xsltproc < 1.1.27 and build root != source root. So, you can use a
recent xsltproc in all conditions, but you can still get the user manual
to build if you are willing to clutter your source tree with build
products, as most of my users will be willing to do.

> I did not use xinclude, so I don't know, wether catalogs are used to
> locate xindluded files.

That sounds like an implementation detail. The xsltproc man page
doesn't say much, other than to reference the W3C XInclude spec, which
doesn't mention catalogs at all.