Skip to content
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

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

Open
shiblon opened this issue Feb 24, 2016 · 7 comments
Open

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

shiblon opened this issue Feb 24, 2016 · 7 comments

Comments

@shiblon
Copy link
Owner

shiblon commented Feb 24, 2016

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
Copy link
Owner Author

shiblon commented Feb 24, 2016

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
Copy link
Owner Author

shiblon commented Feb 24, 2016

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

  • Status changed: WontFix

@shiblon
Copy link
Owner Author

shiblon commented Feb 24, 2016

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
Copy link
Owner Author

shiblon commented Feb 24, 2016

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
Copy link
Owner Author

shiblon commented Feb 24, 2016

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
Copy link
Owner Author

shiblon commented Feb 24, 2016

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

  • Status changed: Accepted

@shiblon
Copy link
Owner Author

shiblon commented Feb 24, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant