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 <levon at movementarian dot 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


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