a couple questions about general makefile design principles

[Robert P. J. Day]

  i'm looking at the makefile structure(s) of an existing project, and i'm 
interested in others' opinions of some design/layout decisions, as i'm not 
sure if those decisions are the standard make approach, or are in some 
ways overkill and could be done in a different way.

  first, there's a top-level included makefile, call it "main.mk", that
pretty much *every* make file at every level is expected to include.  i
don't have a problem with that -- there are some useful macro defines,
such as what i suspect is a fairly common one:

define DO-SUBDIRS
@for d in ${SUBDIRS} ; do \
  ${MAKE} -C $$d $@ ; \
done
endef

that i have no problem with.  but i'm curious about another part of 
main.mk.

  at the top, there are a number of variable definitions, call them 
SHARED, LIBRARY, EXECUTABLE and so on -- types of objects that can be 
built -- all of which are set to the name of another .mk file in that same 
makefile include directory.  each of those files contain rules specific 
for how to create an object of just that type.

  at this point, in any given makefile in the entire SW structure, that
makefile will include "main.mk", but will then, depending on what kind of
object is being created by this sub-makefile, will include the appropriate
makefile containing the appropriate rules for how to create it:

NAMEOFTHING = fred
include main.mk
include ${LIBRARY}

  the above would represent a makefile in a directory where "fred" is to
be used as the name to, somehow, create a library, based on the rules
defined in that included makefile.  if one had, instead, included:

include ${EXECUTABLE}

then the rules would have defined how to create an executable named "fred" 
from whatever the contents of this directory was.  and so on and so on, 
one included makefile for each distinct type of object you might want to 
create.

  on the one hand, i can see how this kind of structure is incredibly 
efficient, which is apparently why it was originally designed this way.
on the other hand, it strikes me that there are a number of drawbacks.

  first, if you happen to take a look at any makefile in the entire 
structure, it's pretty hard to understand what's going on.  i mean, the 
makefile is *so* terse, it tells you almost nothing.

  second, it seems kind of inflexible -- if you want to build a library, 
you use precisely the rules in the included makefile for building 
libraries, and nothing else.  in short, you better want to build a library 
*exactly* the way the original designer had in mind.

  anyway, i don't want to flog this any more than i have.  i'm curious 
about others' thoughts on this kind of structure -- what little i've 
explained of it.

  more questions coming soon.

rday