On Mon, 23 Feb 2009, Tavian Barnes wrote: > 2009/2/23 Ralf Wildenhues <ralf.wildenh...@gmx.de>: > [...] > > generated.c can live in the source or in the build tree. But given that > > different make implementations have slightly different VPATH semantics, > > it may be useful to require it to always live in the source tree; > > further, it may be useful to update it lazily (this shouldn't matter for > > read-only trees iff your dependencies are set up correctly, but it > > should make for faster rebuilds): > > > > $(srcdir)/generated.c: generate.c Makefile.in > > ./generate$(EXEEXT) > tmp-generated.c > > if diff tmp-generated.c $@ >/dev/null 2>&1; then \ > > rm -f tmp-generated.c; \ > > else \ > > mv -f tmp-generated.c $@; \ > > fi > > > > lookup_SOURCES = lookup.c $(srcdir)/generated.c > > I've got it living in $(srcdir) now, thanks. I can't see why your > version of a lazy update would speed it up though. It still runs > ./generate, and now it's running diff too, right?
The version Ralf provided always runs generate but it only updates generated.c (and thereby its timestamp) when the output has changed. This means that Make no longer thinks that it needs to recompile everything that depends on generated.c (lookup in the example above). An example might be if you were to fix the indentation or add a comment to generated.c (or changed anything else that doesn't effect the output) Although I must admit I'm not sure what he means by > > [...] this shouldn't matter for read-only trees iff your > > dependencies are set up correctly [...] I'm not really sure how else you could have generated.c on the source tree and not break dist-check, but then I'm probably missing something obvious. Also, I don't want to split hairs here but isn't it less portable to use $@ in a non-suffix rule? Regards, Allan
