Subject: Re: [Boost-docs] Why not use the xml catalog in Linux?
From: Daniel James (dnljms_at_[hidden])
Date: 2012-02-29 12:59:31
On 29 February 2012 10:10, Philipp Thomas <pth_at_[hidden]> wrote:
> Trying to build the boost documentation on openSUSE fails because the
> stylesheets are in /usr/share/xml/docbook/stylesheet/nwalsh/current (a
> symlink to the current version) and not in
> /usr/share/xml/docbook/stylesheet/nwalsh where boost.book searches.
You can set the path in your user-config.jam file. Something like:
using boostbook : /usr/share/xml/docbook/stylesheet/nwalsh/current ;
> This
> begs the question why you check that at all on Linux. All standard stylesheets and
> dtds can be found via the catalog so /etc/xml/catalog is the only thing that
> needs to be referenced besides the boost.book specific stuff.
I didn't implement it, so I can't say for sure. Probably just to have
a single method for all platforms. It originally required you to
explicitly specify the paths, checking known locations is a pretty
recent addition.
There are problems with relying on the standard catalog. There's a
fairly good chance that on some machines it won't be correct, or will
be missing an entry. For example, if the stylesheets were installed
manually or the packaged versions were uninstalled badly.
> Being not very familiar with JAM (boost is the only package I maintain for
> SLES/openSUSE that uses it), how would I have to change boostbook.jam in
> order to conditionally not use docbook-xsl-dir and docbook-dtd-dir?
>
> Currently I simply use the attached patch for boostbook.jam but that doesn't
> make it conditional on OS.
To automatically support catalog files, it'd need to do is to first
check that the catalog exists and then check that it correctly maps
the relevant paths to existing local files. Or perhaps there could be
some special parameter to say, 'use this catalog', although it'd also
need to somehow know which urls are mapped in the catalog. We're
probably short on volunteers willing to implement such a thing, so I
think the solution is just to add a check for suse's path.
This archive was generated by hypermail 2.1.7 : 2017-11-11 08:50:41 UTC