When are the *.d and *.1st.make file regenerated?

[Joshua Spence]

Hi Chris,

I am still have inconsistent results with the latex document being rebuilt. Here is the output from running make a few times consecutively. As you can see, each time make is run, different files appear to need to be rebuilt. I'm trying to figure out what the issue is, but was wondering if you could spread some light on when the *.d and *.1st.make files should be rebuilt?

Thanks,

Josh

joshua@joshuaj-laptop:~/Thesis/Latex/build$ make

NOTE: You may ignore warnings about the following files:

     thesis.d

= thesis.tex --> thesis.d thesis.pdf.1st.make (0-1) =

= thesis.bib thesis.aux --> thesis.bbl =

= thesis.tex --> thesis.pdf (1-2) =

Success!  Wrote 43 pages, 554078 bytes to thesis.pdf

joshua@joshuaj-laptop:~/Thesis/Latex/build$ make

= thesis.tex --> thesis.d thesis.pdf.1st.make (0-1) =

Success!  Wrote 43 pages, 554079 bytes to thesis.pdf

joshua@joshuaj-laptop:~/Thesis/Latex/build$ make

=  thesis.aux --> thesis.bbl =

= thesis.tex --> thesis.d thesis.pdf.1st.make (0-1) =

= thesis.tex --> thesis.pdf (0-2) =

Success!  Wrote 43 pages, 554079 bytes to thesis.pdf

joshua@joshuaj-laptop:~/Thesis/Latex/build$ make

joshua@joshuaj-laptop:~/Thesis/Latex/build$ 

[Chris Monson]

Basically, these come from the first invocation of latex.

The pdf.1st.make file is the first pdf file that comes out of latex.  Sometimes it's a valid pdf (if there were no errors, latex doesn't need to be rerun, etc.), and sometimes it isn't.  In the cases where it's valid, later steps in the process notice that and just copy it over instead of running latex again.

The .d file is a file that tracks the dependencies for the final pdf file.  So, if you do includes, those will end up in the .d file.  It is generated from several of latex's outputs, including the .aux file, the .fls file, and the various log outputs.  Once generated, if any of the files listed there are changed, the .d file will have to be rebuilt, and latex will run again to do this.

There are several problems with make that cause this process to be somewhat inconsistent.  One of them is filesystem timestamp resolution.  Many modern filesystems have pretty rotten resolution (e.g., on Windows, the resolution is often 2 seconds!).  With that, make has a hard time knowing the difference between a fast-running process, and an out-of-date dependency.  I've wrestled with it for a long time and not found any good general solutions.  It's rather aggravating.

Theoretically, the problem could be solved, sort of, in a hacky kind of way, if make kept around its own metadata about file timestamps, but you can see how that could become wrong in a hurry, as well.

Now, in addition to the timestamp problem, we have issues with latex itself, and the fact that it is a Turing-complete language that uses direct inclusion as its approach to modularity (like #include in C - basically cut-n-paste with language support).  This means that dependency freshness in the fact of external includes is, in its full sense, Recursively Undecidable: you can't know whether a dependency has changed without actually running the program.  Say hello to the Halting Problem.  Furthermore, with some kinds of graphics inclusion, LaTeX refuses to continue when it can't find a graphic - other kinds don't suffer from this issue (graphicx works great, \include of .pstex emphatically does not).

With all of the above explanation, that does *not* mean that the makefile is definitely working correctly all the time.  There could very well be a bug in it that is exacerbating this issue, but it *does* mean that the issue will never be 100% gone.

:-(

-- You received this message because you are subscribed to the Google Groups latex-makefile-discuss group. To post to this group, send email to latex-makef...@googlegroups.com. To unsubscribe from this group, send email to latex-makefile-di...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/latex-makefile-discuss?hl=en-US