[tex-eplain] Indexing and how to determine file dependencies

[Greg Black]

john@wexfordpress.net wrote:

> On Tue, 20 February 2001, Greg Black wrote:
> 
> > john@wexfordpress.net (who doesn't seem to know how to control
> > line lengths sensibly in his mailer) wrote:
> > 
> > > Your incorrect assumption is that the make program has a
> > > useful function to perform in the index creation process. IMHO
> > > it does not.
> > 
> > This is an absurd claim, probably based on ignorance of how to
> > use make.  
> 
> You are then a better person to answer Guy's question. I do
> not create make files because scripts serve my purpose. Given
> the essentially monolithic nature of the TeX process (there is
> no equivalent of the previously compiled module found in
> compiling and linking big software projects) the creation of a
> TeX document will have to process all the bits and pieces
> together in a single run.
> 
> So a script that causes all this to happen does fine for me. 

You already know that many TeX documents are more complex than
this description suggests.  However, there are still a couple of
points to make.  I did not suggest that a script was "wrong",
merely that your take on make was ill-informed.  If a script
works, then that's fine.  However, writing a makefile is no more
difficult than writing a script and, for a complex task, make
may well be both easier to use and simpler to adapt as the
number of input files grows.

> I don't doubt you have used make . What I question is whether
> you acheved significantly better results than you could have
> with a simple script.  If you can educate me on the advantages
> of make over scripting in your products I would be
> grateful. If I can create a large document with three indexes
> in less than half a minute then the script approach is
> certainly feasable. The make aproach would be advantageous if
> and only if you could skip certain steps safely after changing
> certan bits and pieces.

Greater speed or even the ability to skip those few steps that
might be able to be skipped in most jobs are not the reasons to
use make.

Many people, myself included, write their TeX documents using
tools that programmers use -- one set might be emacs for the
document creation/editing and RCS for revision control.  It so
happens that these tools work well with make.  It's s simple key
stroke in emacs to run the make, and it parses the output and
will take me to the source of problems in my documents when that
is required.  And it's easier to have make stop when things go
wrong (since it does that automatically) than it is to add all
that logic to your script.  A script that really does all the
same work as a simple makefile is not a trivial script.

> Similarly TeX/LaTeX does not link previously typeset modules
> of text together. So if chapter 15 changes the entire book
> should be reset via TeX or LaTeX. Pagination may change. The
> Table of Contents may change. Make has no way of sensing these
> changes or the absence of these changes.

Clever use of make can detect more than you realise.  And it's
also true that I often don't care about pagination, contents,
index, etc., because I just want to look at how a particular
chapter will look on the page -- "make chap4.dvi" is great for
that kind of thing.  Then, for the full production, complete
with index proofing, I might use "make preview" and finally it
might be "make production".  It's easy to encapsulate all these
ideas in a makefile and that adds to one's productivity.

Just as a final detail, although TeX does not usefully have
separate compilation and makes it more or less obligatory to
re-run TeX over the entire document for final output, it is
often useful to be able to detect if rebuilding chapter 4 really
does have an impact on later chapters.  This can be accomplished
by storing the individual .dvi files separately and throwing
away newer .dvi files when they compare equal to the older
version.  The comparison cannot be done directly, as each TeX
run generates a different output file; however using a tool such
as my dvicmp (which I'm sure other people have invented as
well), one can compare the significant data of .dvi files.  With
a bit of planning, using tools like this with make can reduce
the work and can save unnecessary re-printing of material that
has not changed.