Re: MacPorts xsltproc is very slow?
От | Thomas Munro |
---|---|
Тема | Re: MacPorts xsltproc is very slow? |
Дата | |
Msg-id | CAEepm=1iP9ies-iJCCbc8QMHbhCD=xytZ4p6-pkzBpRp30taFw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: MacPorts xsltproc is very slow? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: MacPorts xsltproc is very slow?
(Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
|
Список | pgsql-docs |
On Fri, Mar 23, 2018 at 3:27 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Fri, Mar 2, 2018 at 3:34 PM, Thomas Munro > <thomas.munro@enterprisedb.com> wrote: >> I think we should complain to the MacPorts packager about the >> namespace vs non-namespace stuff being possibly confused in the >> packages. > > Any ideas about a workaround for the meantime? Having to wait half an > hour for the documentation to build is pretty annoying. This worked for me: 1. Steal a working installation of docbook-xsl from some other system. Or clone the repo from github.com/docbook and figure out how to build it so that there is an xhtml directory (that was beyond my attention span). I just did this on a Debian system: tar czvf docbook-xsl.tgz -C /usr/share/xml/docbook/stylesheet/ docbook-xsl I could give you that file off-list if you want, but it's 2.2MB so I won't post it here. You could also grab the Debian (or other) package file and unpack that. I created a directory ~/docbook-stuff/ and then unpacked that tarball there. 2. Tell xsltproc to rewrite any references to sourceforge.net to use this local stuff instead. Either you can create/edit the system-wide /etc/xml/catalog file (or equivalent under /opt if you're using MacPorts tools), or you can create a new file somewhere and point to it with the environment variable XML_CATALOG_FILES. I went with the env variable approach because I didn't want to mess with system-wide configuration. So I created a file ~/docbook-stuff/catalog.xml with this in it: <?xml version="1.0" encoding="utf-8"?> <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"> <!-- redirect references to docbook.sourceforge.net to local files --> <rewriteURI uriStartString="http://docbook.sourceforge.net/release/xsl/current/" rewritePrefix="file:///Users/munro/docbook-stuff/docbook-xsl/"/> <rewriteSystem systemIdStartString="http://docbook.sourceforge.net/release/xsl/current/" rewritePrefix="file:///Users/munro/docbook-stuff/docbook-xsl/"/> </catalog> Obviously that needs to be adjusted to point to wherever you unpacked that tarball. I did wonder about simply changing our documentation's sourceforge.net references to point to docbook.org instead, apparently the new home (?) of this stuff: -<xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/chunk.xsl"/> +<xsl:import href="https://cdn.docbook.org/release/xsl-nons/current/xhtml/chunk.xsl"/> (plus similar changes elsewhere). But it didn't seem to be able to fetch stylesheets that way. Perhaps my tools don't like speaking HTTPS. I didn't try to dig any further because I'd rather go and hack on C code today. -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-docs по дате отправления:
Следующее
От: PG Doc comments formДата:
Сообщение: json_populate_* functions have extra undocumented parameter