Re: suddenly, "recursive make considered harmful" makes piles of sense

[Noel Yap]

Alessandro Vesely wrote:

> Boris Kolpackov wrote:
>
> > There is also a third "philosophy": gmake within any directory will
> > build that directory and all its dependencies and any subdirectories
> > and all their dependencies. For example:
> >
> > root
> > |
> > +--libfoo
> > |
> > +--foo
> >
> > Say root/foo depends on root/libfoo. If you say make inside root/foo
> > and root/libfoo is not up-to-date, it will be built before building
> > root/foo. Very handy.
>
> What was that about? Since the manual says "The criterion for being out of
> date is specified in terms of the prerequisites, which consist of file
> names separated by spaces," how can root/foo depend on root/libfoo?

I think Boris was speaking abstractly.  What he really meant was that stuff in 
root/foo depends on stuff in root/libfoo.

> Anyway, I note that the fact that it is named `Makefile' does not
> prevent one for including it. So it should be enough to have one
> of those per directory.

The devil is in the details.  IME, I've found the most effective way to implement non-recursive makefiles is to have two makefiles per directory; one interface makefile (eg GNUMakefile) and one implementation makefile (eg GNUprivate.mk) similar to .H and 
.C files in C++ programming.  It turns out that all the GNUmakefile files wind up to have the exact same contents (but variable semantics since they each live in different directories); I had toyed with the idea of using the MAKEFILES env var or creating 
an alias but didn't want to depend too much on the users' environments to have the build work.  YMMV.

Noel