------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=765
Summary: OS/pkg paths in XSL imports; remote URLs in .xml
Product: Exim
Version: N/A
Platform: Other
OS/Version: All
Status: NEW
Keywords: work:tiny
Severity: wishlist
Priority: medium
Component: Documentation
AssignedTo: nigel@???
ReportedBy: exim-dev@???
CC: exim-dev@???
Created an attachment (id=273)
--> (
http://bugs.exim.org/attachment.cgi?id=273)
Per-OS .xsl/.xml fixups
The documentation XSL imports contain OS-specific (and pkg-specific) paths.
I hacked it once before, then forgot what I did. This time, with SDoP
available, the pain is mostly gone and building is much nicer than it was.
Still, the OS-paths are a problem. If there's a cleaner way to do what I've
done with some installed list of where DTDs are and automatic mappings, then I
don't know it (but I avoid XML). I think there might be some catalog for
mapping public URL identifiers to local location, but since I was already
having to edit the .xsl files I just did the same for .xml too. Re-education
accepted.
So, I added "make os-fixup" as something a documentation builder can do, before
making the documentation. It's not a clean solution, but it lets me build
enough forms of documentation to be able to write doc patches.
In the new OS-Fixups script, define filter_<your_OS> as a sub to do filtering;
the OS value is whatever Perl reports in $^O and I provide filter_freebsd,
which makes these changes:
s{"/usr/share/sgml/docbook/xsl-stylesheets-1.70.1/}
{"/usr/local/share/xsl/docbook/};
s{"
http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"}
{"/usr/local/share/xml/docbook/4.2/docbookx.dtd"};
It gets closer, but I still can't build .info; it does at least let me get
close enough to be able to make spec.txt which will make it easier to provide
documentation patches.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
