Autogenerated .tex dependency for .aux files

8 views
Skip to first unread message

jake

unread,
Jul 27, 2010, 6:23:06 PM7/27/10
to latex-makefile-discuss
When the Makefile encounters main.aux, it automatically generates a
dependency to main.tex, even if main.tex doesn't exist. Why is this
necessary? (This occurs in the get-inputs function; line 1328 in
version 2.2.0-rc2.)

I ask because it causes problems for me when I use the \includefrom
command from import.sty. Suppose I have a main.tex file in the
chapter1/ directory. When I include chapter1/main.tex, main.aux is
generated in the current directory. (I consider this a bug but have
no idea how to fix it.) The Makefile sees the ./main.aux file in the
current directory, assumes a dependency to the non-existent ./
main.tex, and fails.

Here's a minimal example consisting of two files that reproduces the
error:

# File book.tex
\documentclass{book}
\usepackage{import}
\begin{document}
\includefrom{chapter1/}{main}
\end{document}

# File chapter1/main.tex
\chapter{Chapter 1}

The build fails with the error
"make: *** No rule to make target `main.tex', needed by `book.d'.
Stop."

The offending rule in book.d is:
"book.aux book.aux.make book.d book.pdf: main.tex"

If I remove the line "-e 's/\(.*\)\.aux$$/\1.tex/' \" from the get-
inputs function, the document builds properly.

So, why is the .aux:.tex dependency necessary? Will I run into
unforseen problems if I remove it?

Secondarily, does anyone have any leads on how to make sure the .aux
files are generated in the right directory?

Chris Monson

unread,
Jul 28, 2010, 9:23:46 AM7/28/10
to latex-makef...@googlegroups.com
Ah, yes, another person with the includefrom problem.  Sigh.  I just looked at the import.sty documentation, and realized that its use is simply going to break the makefile in spectacular ways.

Using subdirectories for included files has never been well-supported by the makefile, and unless we can change things about "make" itself (including file path parsing, inconsistent backslash escaping, and any number of other oddities that most people simply never run into), that scenario never will be well-supported (or even supported at all).

I know it's sort of an ugly answer to give, but the only way to really use the makefile that works is to put everything that is editable into the same directory.  Imports of non .tex files (e.g., .sty files) are supported from anywhere in LaTeX's path, but .tex files pretty much need to be right there with the main document file.  Otherwise, as you have noticed, everything blows up.

The reason the .tex file is automatically included in the .d file is that if you change it, you want to trigger a rebuild.  Taking that dependency out will break that.  The only real solution is to get the path right.

I just poked around with what includefrom does to the log output to see if this case can be detected.  Unfortunately, the path to chapter1 is only listed in exactly one place in the log file, and that place is unreliable as a source of path information (non-informative and lossy, since we would have to cross-reference ./main.aux with chapter1/main.tex using more than 2 input sources - really, really hard to do in this code).  If the .aux file were to have some indication of the full path, that would be different, but it doesn't.

So, this is just not supported.  In order to make that clear, perhaps I should detect the import.sty package and bail out with a meaningful error.  Otherwise this will continue to confuse folks.

Chris Monson

unread,
Jul 28, 2010, 9:30:58 AM7/28/10
to latex-makef...@googlegroups.com
By the way, I just did a little test.  Have two directories, one called chapter1 and one called chapter2, both with a main.tex file within them.

Guess what pdflatex does in this case?  It overwrites main.aux from chapter1 with main.aux from chapter2.  There is a namespace collision that passes silently.

Just another data point - if you were wanting to split things into subdirectories so that you can avoid such troubles, this won't do it for you.

Sorry I didn't have a better answer, though.
Reply all
Reply to author
Forward
0 new messages