search

shiblon / latex-makefile

A Makefile for LaTeX - drop it in, type make, and magic happens.
Other
185 stars 30 forks source link

If \input dependencies don't exist, the dependency check will fail #166

Open shiblon opened 8 years ago

shiblon commented 8 years ago

Originally reported on Google Code with ID 153

If there is a include file included as \input, and a custom rule in Targets.ini for
creating this include file, the custom rule will not get triggered. The first time
make is run, latex will exit due to not finding the file referred to in the \input,
and the dependency file will not get generated:

---
NOTE: You may ignore warnings about the following files:

     pluggable-roadmap.d

Makefile:2556: pluggable-roadmap.d: No such file or directory
= pluggable-roadmap.tex --> pluggable-roadmap.d pluggable-roadmap.pdf.1st.make (0-1)
=
./pluggable-roadmap.tex:8: LaTeX Error: File `vc._include_.tex' not found.
./pluggable-roadmap.tex:8:  ==> Fatal error occurred, no output PDF file produced!
Error: failed to create pluggable-roadmap.aux
make: *** [pluggable-roadmap.d] Error 1

---

Here, vc._include_.tex is the file referred to by \input. If "make vc._include_.tex"
is run manually once, then subsequent runs of "make" are fine.

The problem can be worked around by adding a custom dependency in Targets.ini of:
pluggable-roadmap.d: vc._include_.tex

Reported by sjmurdoch on 2012-03-16 00:45:08

shiblon commented 8 years ago 
Yes, I'm afraid that you've run up against a fundamental (and not fixable) limitation
of the makefile as it is used with latex.  I'm marking this WontFix, but wanted to
give a brief explanation of why this happens, as well.

When the makefile tries to find dependencies, it does so by running latex (or pdflatex,
or whatever is configured) once.  If that succeeds, then great, there's nothing left
to do.  If it does not succeed, then the makefile parses the logs (and various other
latex outputs) to try to figure out what is missing.

Unfortunately, if an \input is missing, LaTeX *can't* proceed because that input would
normally be included inline, which means that parts of the current document *won't
even parse* unless that file is present.  So, we have a problem.  We can tell that
a *single* input was missing and attempt to rerun LaTeX, but that is often rather expensive,
particularly if there are a lot of generated (or otherwise missing) inputs.

So, we don't do that.  Inputs are either there or they aren't.  Not much can be done
about it, short of implementing my own LaTeX parser to find all of the inputs before
running LaTeX.  As there is no real way of doing that reliably without implementing
TeX all over again, it's just a limitation we have to live with.

Reported by shiblon on 2012-03-21 09:18:43

shiblon commented 8 years ago

Reported by shiblon on 2012-03-21 09:46:17

shiblon commented 8 years ago 
Thanks for the response and I understand the reason for the WontFix, but would it be
possible to mention the limitation in the documentation, along with a work-around?
Also, is the work around I did (making the .d file depend on the file to be input)
the right one to do?

Reported by sjmurdoch on 2012-03-21 14:30:31

shiblon commented 8 years ago 
Workarounds are going to be difficult.

Adding something to the .d file is problematic because it is regenerated every time
the main source file changes.

You might, however, be able to create a custom *additional* dependency for the .d file,
perhaps something like this:

myinclude.tex: myinclude.tex.source
   command_to_build_from_source $< $@

mymainsource.d: myinclude.tex

That might possibly work.  If it does so reliably, I could totally see us adding that
to the documentation somewhere.

Reported by shiblon on 2012-03-22 06:30:19

shiblon commented 8 years ago 
My Target.ini seems to be roughly what you suggest, and that approach works for me:
https://gitweb.torproject.org/sjm217/torspec.git/blob/54508c84314754755d8df05242740c82bb7aa360:/proposals/ideas/xxx-pluggable-roadmap/Targets.ini

Reported by sjmurdoch on 2012-03-23 19:05:56

shiblon commented 8 years ago 
Sorry to be so slow to respond - work heated up.

This looks good as something we could add to the documentation.  If you don't mind,
could you let me know where the most obvious place would be for it?  We could also
add something like this to the project wiki, really (sparse as it is).

Reported by shiblon on 2012-08-02 09:22:30

shiblon commented 8 years ago 
I'd suggest adding the documentation to the section of help under Targets.ini. That's
where I first looked and it's where the new make rules need to go. I think where the
help goes is less important than that it should include '\input' somewhere so people
can search for it.

Reported by sjmurdoch on 2012-08-26 14:07:51