[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 <levon@movementarian.org> writes: [...] JL> This is moving very far away from my original point. It is not JL> just the location of the docbook stylesheets I need to deal with, JL> as I have mentioend already - I must also deal with srcdir JL> vs. objdir issues for the location of the XML + XSL source files, JL> which is in a different directory to $cwd when building in such a JL> fashion. I understand, and it's why I am suggesting the catalog.in extraction as a possible generic solution. JL> I am not not even providing RPMs ! This issue is totally unrelated JL> really. No it isn't unrelated, because my point was that pre-built "binaries" (they aren't really binaries in this case) whether they be RPMs or .deb or whatever, are about the only way to reliably distribute packages for non-developers. Whenever you have to rely on extra packages that aren't in the base distro, or are packaged in different ways in different distros, you are bound run into these kinds of issues. It's not such a problem for C programs, again because GCC is mature and pretty much standard for all distros at this point, whereas the whole libxml2/libxslt/catalog structure depends on how carefully the distro cares about packaging those tools (e.g. if the distro in question isn't automatically updating /etc/xml/catalog when the docbook-xsl-style package is installed, it isn't doing a good job of packaging and you should complain to the distro about it). Ultimately when XML/XSL tools become as important as compilers on a given system then the tools will start to become more standard, however the fact that is more than one standard set of XML/XSL tools available (libxslt, Saxon, Xalan) does make standardisation a bit more difficult (e.g. there's only one GCC out there). [...] >> This way I keep don't need to have any .in files for my stylesheets >> and XML files, and I can isolate all the substitutions to one file: >> catalog.in. JL> Can I get this source somewhere ? (CVS tree + approximate date, JL> tarballl, whatever ?). There is a version of this available publically that I used for generating docs for an open-source project with the old Jade/JadeTeX DSSSL toolchain before I switched to xsltproc, that's available (it does catalog extraction and shows the general approach, but it's probably not worth looking at in too much detail right now, since I haven't got around to switching to xsltproc and it uses old-style SGML catalogs): http://savannah.nongnu.org/cgi-bin/viewcvs/swarm/docs/swarmdocs/ I will see what I can come up with your test case and send to you. >> Can you send me (off-list) a complete (small) self-contained test >> case that demonstrates this problem, and I'll test it on my system. JL> I'll do this when I do the same for the newer libxslt - thanks. Got it, thanks. Alex
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]