Join GitHub today
FreeBSD fails build PDF output with sphinx 1.8 #6021
FreeBSD has texlive-2015 and it does not have xindy. As a result running the
The RTEMS project's documentation is built with sphinx-build we cannot update to 1.8. Our servers run FreeBSD.
I cannot find a way to work around this issue. We seem to need
Are you using
Have you tried with
then something is wrong.
I would clean up entirely the LaTeX build repertory and try again, but possibly you did that already.
Ok, I checked your project and your build process seems to bypass the Sphinx provided Makefile in build repertory, as a result
I forced usage of this via hand-editing filr
because I did not know how to set
as you see above it ended however in some other unrelated error. (I am using Python 3.6.8).
But as regards your LaTeX question the crucial line
is missing from console output in your project way of building the PDF. I obtained it by adding the
By the way, your configure script checks for some LaTeX packages which are not used anymore by Sphinx (threeparttable for example, probably others).
I see there is some use of
Waiting for feedback then I will close this as this is not issue of Sphinx.
(edit: all the above is done with current dev version of Sphinx 2.0.0+/3e0c65a245)
Thank you for the quick response and for taking a look at our issue and project. FYI moving our project to Sphinx has been really good. Last year we had Google Code In students sending in patches.
Yes and this something I would like to fix. I would like to move to using your generated
OK. This seems important.
Agreed, this is our issue.
Thanks for this and as you say if the macro is defined in this file it explains what I am seeing. I will investigate.
Thanks. We have some users building on older version and some of this came from an old CentOS user. I should revisit this.
That is understandable. What you have given me here is really great. I inherited the minted parts and I have not looked into what it does.
I agree it would be nice.
Agreed. I should have raised this as a question, I am sorry about that.
OK. I am on a pip latest which seems to be 1.8.
For the record, with
I am busy today, regarding the
you reported on executing directly gmake, it can only happen if
You see no attempt at using
But then the build aborts with
And indeed, to use
In brief, I think your dependency on
I need to examine more the xelatex situation. Can't today.
Thanks. I have raised a bug report on this issue in the RTEMS project.
I have disabled xindy in this patch ..
Thanks for this. I will look at removing it.
Excellent. Has the Makefile always been in Sphinx? I am wondering about users on older version of Sphinx.
No problem, I am on the road for a week. There is plenty here for me to sort out.
this is nothing special, it happens anytime one has done a manual run of
It seems to have been added at fbe9ed5 in 2007, so yes, it has always been there in the latex build repertory... The move to use
This makes sense.
Thanks, this is good to know.
I just pushed patches today that provides the ability to switch to use
@kiwichris waf has its own handling of LaTeX builds. Now, it can't replicate in a few dozen lines of Python code the expertise one finds in the Latexmk Perl script for compiling LaTeX sources in the right way. I don't know how to inject usage of Latexmk in waf build system, I guess one would have to disconnect all the waf native handling of LaTeX. Sphinx ships a Makefile which is needed to handle usage of platex+dvipdfmx which is not possible with waf (at least the version of your project) but this is not relevant to you (it is for Japanese documents), and some specific configuration of xindy, which is not relevant to you either as even with xelatex you will use
Older version of Sphinx Makefile did not use Latexmk and had simple logic which was probably less refined than the waf way of handling LaTeX builds. But with Latexmk we have (since Sphinx 1.6.1) appropriate tool for the kind of LaTeX sources produced by Sphinx, even with extensions beyond Sphinx proper (I trust). This adds a Perl dependency but incorporates a more sophisticated LaTeX build set-up than the waf provided one. If one does multiple times Latexmk after changes in tex file, it knows how to minimize the number of pdflatex runs. (it also computes hash sums and has its own auxiliary files to detect what changed; in particular it analyses the Latex log file in ways which I doubt waf build system does).