Build error in users guide in HEAD of today
Dear GHC-ers, I'm trying to put together a virtual machine with a default development for GHC hacking. To test it, I was running "sh validate" in the build tree. There were build errors in the doc/users_guide, however. Google gave me an hpaste page with the error on it, but I couldn't find the referring message. Does this ring a bell for anyone: latex failed users_guide_tmp.tex:1380: Undefined control sequence \Documents. users_guide_tmp.tex:1380: leading text: } users_guide_tmp.tex:1380: Undefined control sequence \user. users_guide_tmp.tex:1380: leading text: } users_guide_tmp.tex:5782: Undefined control sequence \Documents. users_guide_tmp.tex:5782: leading text: ...kurl{C: \Documents~And~Settings\user\ghc} users_guide_tmp.tex:5782: Undefined control sequence \user. users_guide_tmp.tex:5782: leading text: ...kurl{C: \Documents~And~Settings\user\ghc} users_guide_tmp.tex:5782: Undefined control sequence \ghc. users_guide_tmp.tex:5782: leading text: ...kurl{C: \Documents~And~Settings\user\ghc} users_guide_tmp.tex: File ended while scanning use of \hyper@n@rmalise. users_guide_tmp.tex: Emergency stop. Error: latex compilation failed make[2]: *** [docs/users_guide/users_guide.ps] Error 1 make[1]: *** [all_docs/users_guide] Error 2 I understand the LaTeX errors, but I'm not so well versed in docbook. Should the path in the ghci.xml and packages.xml be forward slashed, instead of backslashed or does this indicate there's something wrong with my docbook/latex setup? Even when I change the backslashes to forward slashes, the last error (scanning use of \hyper@n@rmalise) remains. Any ideas? Regards, Philip
On Aug 20, 2009, at 11:43 PM, Philip K.F. Hölzenspies wrote:
latex failed users_guide_tmp.tex:1380: Undefined control sequence \Documents. users_guide_tmp.tex:1380: leading text: } users_guide_tmp.tex:1380: Undefined control sequence \user. users_guide_tmp.tex:1380: leading text: } users_guide_tmp.tex:5782: Undefined control sequence \Documents. users_guide_tmp.tex:5782: leading text: ...kurl{C: \Documents~And~Settings\user\ghc} users_guide_tmp.tex:5782: Undefined control sequence \user. users_guide_tmp.tex:5782: leading text: ...kurl{C: \Documents~And~Settings\user\ghc} users_guide_tmp.tex:5782: Undefined control sequence \ghc. users_guide_tmp.tex:5782: leading text: ...kurl{C: \Documents~And~Settings\user\ghc} users_guide_tmp.tex: File ended while scanning use of \hyper@n@rmalise. users_guide_tmp.tex: Emergency stop. Error: latex compilation failed make[2]: *** [docs/users_guide/users_guide.ps] Error 1 make[1]: *** [all_docs/users_guide] Error 2
Dear GHCers, It seems the last error is also due to backslashes in windows paths in the documentation. When I replace latex with a script that interrupts for user interaction and manually change all paths in /tmp/tmpXXXXXX/ users_guide_tmp.tex to have double backslashes, it all works fine. Is there a problem with the hyperref package that fails to properly escape (i.e. insufficient verbatim) the contents of the \nolinkurl{} macro, or should docbook have escaped the backslashes? Regards, Philip
Hi, I had the same problem. I'm using the dblatex (version 0.2.10) from macports (on OS X 10.5.7), which isn't the latest version of dblatex. Also I'm using the MacTex 2008 Tex distribution, but I have no idea what the particular versions of the url or hyperref package are. Anyhow, I solved this particular problem by changing the style sheets in my dblatex install. I found them under: /usr/local/share/dblatex/xsl In the 'url.xsl' stylesheet I replaced the nolinkurl template with the following: <xsl:template name="nolinkurl"> <xsl:param name="url" select="@url"/> <xsl:text>\protect\nolinkurl{</xsl:text> <xsl:call-template name="scape-encode"> <xsl:with-param name="string"> <xsl:call-template name="scape-replace"> <xsl:with-param name="string" select="$url"/> <xsl:with-param name="from" select="'\'"/> <xsl:with-param name="to" select="'\\'"/> </xsl:call-template> </xsl:with-param> </xsl:call-template> <xsl:text>}</xsl:text> </xsl:template> So yeah, basically it is a mechanization of your manual solution. Maybe you should bring this up with the dblatex folks? They have this bug report on it [1], but the appearently they could not reproduce it with 0.2.11. I can't verify if it is indeed solved with 0.2.11 and onwards, and have no intention of doing so as I'm satisfied with my current solution. Hope this helps you for now. Regards, Christiaan [1] http://sourceforge.net/tracker/index.php?func=detail&aid=2028163&group_id=72...
participants (3)
-
"Philip K.F. Hölzenspies" -
Christiaan Baaij -
Ian Lynagh