DOCBOOK-APPS: Re: srcdir/objdir issues and including variableusability issues with xsltproc

[Alex Lancaster <alexl@users.sourceforge.net>]

[Apologies in advance for ignoring my own advice to move thread, I
think that are issues with packaging third-party DocBook modules that
are relevant for this list].

>>>>> "JL" == John Levon <levon@movementarian.org> writes:

[...]

>> 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?

JL> "Linux". IOW, anything really.

OK, but you still haven't told me what distro that you are having
trouble with in the first place.  My point is that until the FHS, the
LSB (Linux Standard Base) and distro packaging become more precise on
this point, as you've discovered, the XML/XSLT "experience" is going
to be distro-specific.  Generally it's hard to provide a tarball that
installs as flawlessly as a "binary" or pre-built package for a given
distro.  My general strategy is to provide a tarball for developers or
at the very least for somewhat savvy, sophisticated users, which means
that some tweaking may be necessary; and I provide pre-built "binary"
packages (.rpm, .deb or .tgz) for novice users.  In the case of RPMS,
there's no such thing as a "generic" distro-independent RPM, so you
need to provide one for each distro (because of all the different
oddities you've experienced), which is a pain, I agree, but it's
really the only reliable way to do it.  Providing an .rpm for Red Hat
and a .deb for Debian will normally keep about 80% of your users
happy.

[...]

>>  If you are running Red Hat

JL> Ah, but he isn't. An example from the wild that its existence can
JL> by no means be relied on ...

I don't mean to be parochial about Red Hat, I use Slackware and Debian
frequently too, but I had to choose a system to demonstrate how it's
*supposed* to work... ;-)

>> 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

JL> ... yet. This FHS proposal sounds great.

What I used to do before I could rely on /etc/xml/catalog for Red Hat,
is that I had my configure script checking for the docbook stylesheets
and DTDs using some heuristics looking for
/usr/share/{sgml,xml}/docbook-* type paths, then generated catalog
entries for the DTD and the stylesheet from my catalog.in file.  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.

>> 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.

JL> OK, but its just ="docbook.xsl" which should find the one in the
JL> catalog according to the docs you gave me. I will try a current
JL> version of xsltproc as suggested by Daniel later.

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.

>> 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.

JL> I think -I has been around for quite a while :)

My point is that XSLT technology is still relatively immature.

>> However, there's nothing stopping you right now writing another
>> wrapper on top of xsltproc to make it behave somewhat similarly to
>> "gcc -I".

JL> Sure, if I knew how, which I believe is the subject of this
JL> discussion ;)

And the answer is to manipulate catalogs behind the scenes.

Alex