[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: DOCBOOK-APPS: Re: srcdir/objdir issues and including variableusability issues with xsltproc
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 No, I am talking about my distributed tarball being buildable on another system that I have no control over. > 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. This is pretty much irrelevant - not everybody has Red Hat. > 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"/> You say you didn't modify it, yet you have a more recent version of xsl-stylesheets than Red Hat distribute ? Anyway, although I have these entries : <phe> /etc/xml doesn't exist This would indicate there is some way to go before this can be relied on (and yes, he does have the stuff installed and working). > XML_CATALOG_FILES=catalog:/etc/xml/catalog I can't rely on the location or existence of such a file. I hope that won't break xsltproc - I'll try your solution. OK I've just tried it again with : XML_CATALOG_FILES=xsl/catalog.xml:/etc/xml/catalog xsltproc -o \ oprofile.html --stringparam version 0.6cvs ./xsl/xhtml.xsl \ ../doc/oprofile.xml Same error. > I agree with your point that it would be nice if XSL would allow > variable substitution (as it does for other <xsl:param/>s) in > <xsl:import/> and <xsl:include/>, but it's a limitation of the XSLT > 1.0 spec, not a limitation of xsltproc itself, Sure. > 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). Compare and contrast with gcc -I. It's crazy. I'm quite sure catalogs admit of some very clever things, but it seems they forgot about the basic things. regards, john
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]