-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make latex
able to rebuild only what is needed, just as make html
?
#13181
Comments
This is an interesting idea which however will speed up only the I think a start of a similar conversation was done already on this site but don't have a link at this time. Anyway, thanks for proposal. |
@jfbu "Joining" all small PDF's will make all of them start a new page and at the top of the page, which isn't what is expected, is it? IMHO, obtaining only a small PDF would be just for checking the layout of the modifications just done in a single source file. |
The way HTML is organized part of the build is split across several files that are linked (e.g. rebuilding a single page assumes no significant changes happened to the index) but PDF is different in that it's compiled so to rebuild one part you have to rebuild the whole thing, compile it and finally compress it. (Not to mention any LaTeX magic that may also impose requirements on the final document that HTML does not.)
With HTML output the build process isn't as simple as it may seem, if you're changing CSS, JS, or some included SVG the build won't detect changes to those files so any change also requires rebuilding the whole project. It's tedious, I know..! |
@electric-coder I understand that the “normal” PDF output requires to rebuild the whole thing: currently My point here is: it would nice for
Hence, if what is to be rebuilt is:
|
@dbitouze LaTeX isn't my forte but I don't think that having "individual PDFs" would speed up the build of the final monolith due to requirements on internal consistency that HTML does not impose but the other formats do. So, if there's an omission in the index both PDF and LaTeX are likely to throw errors whereas a split HTML won't.
Your argument is somewhat conceptual but, as @jfbu hinted, that's just not how the other document's build process works because there are requirements on internal consistency, it seems LaTeX itself doesn't provide the necessary underlying tooling: see Does LaTeX have to reprocess included files that haven't changed? |
Indeed, of course.
I see. I understand the idea. I see one major difficulty regarding cross references, when working with If we were to produce "atomic" ones via Sphinx we would also have to revisit the whole way cross references, especially footnotes, are resolved by the Sphinx LaTeX builder, which has been worked out with a "single document" in mind. Sphinx does produce mark-up in the output called I think your problem is of realistic concern only for big projects which have a significant build time for the PDF build phase, and that for most of them, checking the HTML build is a better alternative, I mean by that few people are really interested into checking the impact of a local change into the PDF build. I do think the issue is interesting to discuss, but Icross-references not being to solely other "web pages/documents" but having to know the final page number in the final big PDF, this whole topic looks like a rather difficult one, for a (as I can judge but I may be wrong) somewhat "niche" (I hope this works in English) purpose. |
But that's not what I'm about :) My aim is not to speed up the construction of the final monolith, just to be able to construct a partial PDF containing only the few pages corresponding to the modified source file(s). For example, our LaTeX FAQ is made up of almost 1400 source files ( |
You're right about
|
Lets split this sentence:
The two common alternatives: A. Construct a second B. Same as the above but keeping a "development" version of your docs separately from the "production" version where you selectively wrap whatever is causing delays (the main toctree) in an
Here Sphinx itself keeps track of changed files (the manual solutions above being obviously inconvenient). It's a lot easier to just use the alternative proposed by @jfbu
So a development convenience tool (as a builder CLI flag) to build just the the latest changed sources as individual PDFs ignoring any internal inconsistencies arising from incompleteness (a kind of |
Is your feature request related to a problem? Please describe.
I'm always frustrated when I have to recompile the whole PDF of my project, even though only one of its many source files has changed, whereas, for HTML output, only the corresponding HTML file is rebuilt.
Describe the solution you'd like
It would be nice to have
make latex
asmake html
able to rebuild only what is needed. For this, make latex would have to copy the HTML builder but it looks needed then for its mechanism to produce in build repertory as many.tex
files as there are source files. Hopefully it should be possible from one extra "main" file to "input" all the small "unit files". Is this possible?The text was updated successfully, but these errors were encountered: