On Fri, Jul 16, 2010 at 11:35 AM, Josh Bialkowski <[email protected]> wrote: >> What it should do (IMHO) is search through parent directories as well, but >> it doesn't. > > Couldn't you make it do that with VPATH?
There may be a clever trick I don't know, but as far as I can tell there's a catch-22 here because you'd need to have some kind of makefile to set up VPATH first, which entails having a stub makefile in each dir, and once you've gotten to that point there are better options as discussed. And in terms of finding VPATH via the environment, the manual (http://www.gnu.org/software/make/manual/make.html#Makefile-Names) is pretty clear that "If make finds none of these names, it does not use any makefile..." >> 1. "Local" variables need to be uniqified, e.g. $(lib1_objects) instead of >> $(objects). Advanced topic: one of the interesting things about make is that variable names can contain just about any character. This means, among other things, that paths can be part of variable names. So at large enough scale it may make sense to uniqify names using the dir name in an automated fashion. I.e. instead of $(lib1_objects) you'd use $($(thisdir)_objs) where thisdir can be determined from MAKEFILE_LIST as shown. I've done this; it scales well, at some cost to readability. Which puts me in mind of another advanced topic: a side effect of using fully-qualified pathnames is that the Makefile should be completely insensitive to the cwd. This can be easily tested; cd to some random place like /tmp and try "make -f /path/to/master/Makefile". It should work exactly the same. >> And then your build clauses would look mor or less like >> >> $(PROJECT_ROOT)foo.o: $(PROJECT_ROOT)foo.c: >> $(CC) -c -o $@ $< Although it's an orthogonal topic, it's a good idea to use implicit rules as much as possible. Especially in this model as it saves typing long pathnames and makes Makefiles more robust in the event of refactoring/renaming. Other things to read: - Take 2 minutes right away to read http://mad-scientist.net/make/rules.html. - When you have something working, read http://mad-scientist.net/make/autodep.html for dependency generation ideas. - And if you support or ever might support multiple target architectures: http://mad-scientist.net/make/multi-arch.html - You might also want to look into GMSL (http://gmsl.sourceforge.net/). I've never used it myself but there's a lot of clever stuff there, freely available. David Boyce _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
