Awesome-CV/Makefile

.PHONY: examples

examples: $(foreach x,coverletter cv resume,examples/$x.pdf)

%.pdf: %.tex
	xelatex -output-directory=$(dir $@) $<
make: fix dirty check, support concurrent build 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. 2016-08-09 15:58:28 +00:00			`.PHONY: examples`
Added stackoverflow, makefile for testing changes. 2015-12-05 21:05:24 +00:00
make: fix dirty check, support concurrent build 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. 2016-08-09 15:58:28 +00:00			`examples: $(foreach x,coverletter cv resume,examples/$x.pdf)`

			`%.pdf: %.tex`
			`xelatex -output-directory=$(dir $@) $<`