Not really directly C-related, but I've done fine with it for cases where the
things being built are NOT a single unified app, but rather, a selection of
logically-independent things. Even then, it's not awesome, and it's not clear
to me that there isn't a better way.
I think I'd reason like this:
- If they really /are/ independent things, they should be built
separately, each with its own Makefile, and no top-level one.
- If they aren't, I write a single Makefile which treats directory
components as part of the filename. No VPATH or anything like that.
I use libraries to divide and conquer if the number of files gets
too high:
libfoo.a: foo/bar.o
libfoo.a: foo/baz.o
libfoo.a: foo/bat.o
Come to think of it, I have some code that uses recursive make for packaging
because some of the things in it contain sub-things. And it's not bug-free or
hassle-free, but it's been better than the alternatives I thought of in terms
of "that took five minutes and now I can get back to code".
The cost of broken dependency tracking comes (if it comes) much later,
when you start debugging faulty builds, or develop the habit "I'll
do another 'make clean' just to be sure".
Also, with the small--medium projects I've been in, it's not really
harder to write one Makefile than one per directory. Not with Gnu
Make, anyway.
/Jorgen
