if we hardwire the build script in the target commands, then what we
want to do remains opaque to make. it is better to speak make's
language, so it understands us, so we can rip the benefits from that.
we don't have 1 test target, but 3: the 3 pdf examples. when we extract
3 rules from the 1 we have right now, make gets to understand what we
want to do:
* understand there are 3 steps to the build, not 1
* understand what are the products that will yield (pdfs)
* understand products' dependencies (texs)
* understand the products are independent of each other
when make gets to know what the products and their dependencies are, it
can tell when there is no work to do. for example, if a pdf is already
there, and its tex dependency hasn't changed, there is no need to
re-compile the pdf.
when make knows the products are independent of each other, and we
compile with make -j, then it can build faster by compiling the pdfs
concurrently, rather than serially one after the other.
and, there is an additional benefit here: we can compile a particular
pdf, and not the others: make examples/cv.pdf.
finally, note that because now make can tell when there's nothing to do,
you might be surprised if, for example, on a pristine checkout of the
repository, you run make, and make responds
make: Nothing to be done for `examples'.
this is because the pdfs are checked in, and make sees the texs haven't
changed since they were last compiled. to force a build as was the case
before, run make -B. alternatively, you can touch any of the tex files,
and make will recompile the touched texs.
