Open christianlupus opened 4 years ago
I'm pretty sure that the generation of the dependency files is deterministic. It's just wrong.
Yeah, I should have written appears non-deterministic to the user without further research. I was first a bit stunned as I assumed the file content would only depend on the TeX file but not the state of the dep
file itself.
It also doesn't “appear non-deterministic” to the user. Non-determinism has an entirely different meaning.
Brief outline of the bug
The externalization library produces wrong dependency files in mode
list and make
.I am not relying on the update checking mechanism using md5 as it involves a compile run of the main file to update the md5 sums. Normally, I keep it active, but while developing on the images it is much more convenient for me if I can simply call
make images
and all required images are rebuilt without the whole project. This is especially true for beamer presentations with overlays where not only one image but a series might be built.Minimal working example (MWE)
The MWE consists of three files in total as I need to focus on the dependency file generation by the tikz external library.
The idea here is to just import a tikz external file into the document by a self-written macro. This will do other things as well in the real world but here this is sufficient.
Just some arbitrary image code. Please note that the dependency declarations are commented out for now.
Further, I need a file
imga.tikz
. You can simply copy the code over fromimgb.tikz
.Now do the following steps
pdflatex
andmake
as isimgb
and recompileimga
and recompileWhat I expect
Each time the
mwe.*
files are updated and themake
command will build amwe-figure0.*
bundle. I am focusing now on themwe-figure0.dep
file.mwe-figure0.pdf
dependent onimgb.tikz
.imga.tikz
What I get
mwe-figure0.dep
is emptyYou can test any combination in (3), compile it, and comment all in (3): You will always get the same dependencies as if the file was not touched at all. I cannot tell, if this is really the case or not.
Additional comments
The occurrences in (1) and (2) are somehow redundant. I just wanted to avoid that it needs to be exactly before the
tikzpicture
itself.In fact, there are 2 sub concerns that I assume to be related (thus one bug report):
tikzpicture
. According to the manual it should also work for the next picture.dep
file is not altered at all.