Build failure on macOS 10.13

[fxcoudert]

The error is as follows:

Making install in man5
/usr/local/opt/asciidoc/bin/a2x -d manpage -f manpage -L tinyproxy.conf.txt
a2x: ERROR: "xsltproc"  --stringparam callout.graphics 0 --stringparam navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics 0  "/usr/local/Cellar/asciidoc/8.6.9_1/etc/asciidoc/docbook-xsl/manpage.xsl" "/private/tmp/tinyproxy-20170929-9105-1mddtrj/tinyproxy-1.8.4/docs/man5/tinyproxy.conf.xml" returned non-zero exit status 5
make[2]: *** [tinyproxy.conf.5] Error 1

[Muffinman]

Is there any work-around for this? ;(

[rofl0r]

the workaround i usually use is 1 ) create file called "a2x" which contains "#!/bin/true" and i chmod it +x, then add the current directory to $PATH as first element, so our dummy a2x executable gets used. and at the same time i touch tinyproxy.conf.txt

[Muffinman]

@rofl0r Thanks, I'll give this a go!

[Muffinman]

I got mine working by doing the following:

1. Update the automake tools so that the configure process works, & install asciidoc

   brew install automake
   brew install asciidoc --with-docbook-xsl

2. Store path to XML Catalog Files so that make can

   export XML_CATALOG_FILES=/usr/local/etc/xml/catalog

3. Install through brew (I was also able to manually compile from the source)

   brew install tinyproxy

I'm not sure if there's a cleaner way of compiling using the standard OSX automake binaries?

[rofl0r]

i don't know. and tbh, this asciidoc dependency is a thorn in my eye since day one, and already caused myself hours of inconvenience, and other users too. so i'm pondering if there's a way to remove it completely. maybe i can convince @obnoxxx that we just generate the docs once on our development machine, check them in, and then just use sed on the generated files to change the version numbers and install locations.

[apjanke]

I think the consensus at Mac Homebrew, which has seen a2x problems here and elsewhere, is that these failures are due to intermittent network/server issues with Sourceforge. (See https://github.com/Homebrew/homebrew-core/pull/20227) By default, asciidoc's a2x program retrieves a bunch of XML files from Sourceforge to use in its transformations. If one of those downloads fails, you'll get this error. They're not cached locally; it goes to the network every time.

That --with-docbook-xsl/XML_CATALOG_FILES=/usr/local/etc/xml/catalog fix works around it by having a2x use previously-downloaded local copies of those XML files instead of downloading them at execution time. (Though Homebrew is using a slightly different format for it these days. I've checked in a fix for Homebrew's tinyproxy formula that does this, so Homebrew users will always get the workaround.)

As a workaround, you could add a --without-asciidoc option to configure which forces a2x to be skipped, even if it's detected locally. But users would have to know to use it in response to these errors. Or you could require the docbook-xsl files to be installed locally, though that's another annoying dependency.

For a real fix, you might switch from asciidoc/a2x to Asciidoctor. asciidoc the program is no longer maintained, even though AsciiDoc the format is still in use. Asciidoctor is a newer, currently supported implementation of AsciiDoc. (asciidoc themselves suggest it in their final release notes.) And its manpage backend does not have a network XML download dependency like a2x's does, so it's not subject to this issue. asciidoctor -b manpage <foo>.txt will do the manpage conversion.

[rofl0r]

my preference would be to just generate the manpage with a2x once, and then embed it into the repo as .in file which can have some stuff like @VERSION@ in it, which can then be replaced using sed to create the final product. from then on, the manpage can be edited directly in the source control, and the dependency on a2x removed entirely. imo this caused too much headache already.

[apjanke]

That makes sense too.