[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: DOCBOOK-APPS: 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@gnome.org. Cheers, Alex
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]