This is the mail archive of the docbook-apps@lists.oasis-open.org mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: srcdir/objdir issues and including variableusability issues with xsltproc


>>>>> "JL" == John Levon writes:

JL> On Sat, Mar 08, 2003 at 04:20:20AM -0800, Alex Lancaster wrote:
>> case it's not a direct contradiction.  If you are talking about the
>> users installing the basic tools on the system as well, then
>> clearly extra configuration is necessary, but you can hide it from
>> the user

JL> No, I am talking about my distributed tarball being buildable on
JL> another system that I have no control over.

Fine, I see that now. So you are currently using autoconf to help with
the build to autodetect xsltproc etc. is that right?

>> You don't specify what system you have.  Since you're using rpm,
>> I'm would assume probably Red Hat or a RPM-based distro.

JL> This is pretty much irrelevant - not everybody has Red Hat.

OK, but I was trying to guess what system that you are actually using
so that I could tailor my comments accordingly.  What systems are you
planning to deploy on?

>> But they do.  Here's my /etc/xml/catalog on Red Hat 8.0 (I did not
>> have to modify it all):

>> systemIdStartString="http://docbook.sourceforge.net/release/xsl/current";
>> rewritePrefix="file:///usr/share/sgml/docbook/xsl-stylesheets-1.58.1-1"/>

JL> You say you didn't modify it, yet you have a more recent version
JL> of xsl-stylesheets than Red Hat distribute ? 

It's an update I pulled from Rawhide, but it's a version that Red Hat
distribute, a Red Hat-built RPM.  But yes, you got me, it's not from
the base Red Hat 8.0 distribution.  However, the version from 8.0
behaved exactly the same, the post-install script installed the
catalog entries correctly in exactly the same manner.

JL> Anyway, although I have these entries :

JL> <phe> /etc/xml doesn't exist

If you are running Red Hat, this should be part of the xml-common
package:

$ rpm -qf /etc/xml/catalog
xml-common-0.6.3-12

This is a required package to install docbook-style-xsl.

JL> This would indicate there is some way to go before this can be
JL> relied on (and yes, he does have the stuff installed and working).

>> XML_CATALOG_FILES=catalog:/etc/xml/catalog

JL> I can't rely on the location or existence of such a file. I hope
JL> that won't break xsltproc - I'll try your solution.

The /etc/xml location is rapidly becoming the standard on most
GNU/Linux systems to locate the XML catalog for the system, and it has
been proposed that it be added to the FHS (Filesystem Hierarchy
Standard), which is why xsltproc looks for it by default.  It
shouldn't break xsltproc if it doesn't find it, it just won't be able
to do any local catalog resolution and will attempt to fetch any URIs
mentioned in your document (e.g. DTDs, stylesheets) over the net
directly (unless you specify the --nonet option).

JL> OK I've just tried it again with :

JL> XML_CATALOG_FILES=xsl/catalog.xml:/etc/xml/catalog xsltproc -o \
JL> oprofile.html --stringparam version 0.6cvs ./xsl/xhtml.xsl \
JL> ../doc/oprofile.xml

JL> Same error.

It's difficult to help debug this without a full test-case.  I suspect
it's related to some relative-path resolution with the way you've set
up the directory structure.  When you are resolving href's inside
<xsl:include>, they are relative to the current location of that XSL
document, but I can't say without seeing more.

[...]

>> I've run into the same problem as you, and initially I was
>> frustrated, but with XML catalogs and a little make and shell it's
>> possible to do most of what you want without too much fuss (if you
>> encapsulate in way that hides the details from the user).

JL> Compare and contrast with gcc -I. It's crazy. I'm quite sure
JL> catalogs admit of some very clever things, but it seems they
JL> forgot about the basic things.

Well, GCC'S been around for a lot longer than XSLT and many options
now exist in GCC that probably weren't in the original implementation.
However, there's nothing stopping you right now writing another
wrapper on top of xsltproc to make it behave somewhat similarly to
"gcc -I".  You could even submit a patch to Daniel Veillard! ;-)

Anyway, this is rapidly going off-topic, we should probably move this
thread to the libxslt list: xslt at gnome dot org dot 

Cheers, Alex


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]