Larger projects are usually structured into a nummber of sub-directories, each of which has its own `Makefile'. (In very large projects, this sub-structure might be iterated recursively, though that is rare.) To give you the idea, here's part of the directory structure for the (rather large) `ghc' project:
$(FPTOOLS_TOP)/ghc/
Makefile
mk/
boilerplate.mk
rules.mk
docs/
Makefile
...source files for documentation...
driver/
Makefile
...source files for driver...
compiler/
Makefile
parser/...source files for parser...
renamer/...source files for renamer...
...etc...
The sub-directories `docs', `driver', `compiler', and so on, each contains
a sub-component of `ghc', and each has its own `Makefile'.
There must also be a `Makefile' in `$(FPTOOLS_TOP)/ghc'.
It does most of its work by recursively invoking `gmake'
on the `Makefile's in the sub-directories.
We say that `ghc/Makefile' is a non-leaf `Makefile',
because it does little except organise its children, while the `Makefile's
in the sub-directories are all leaf `Makefile's. (In principle
the sub-directories might themselves contain a non-leaf `Makefile' and
several sub-sub-directories, but that does not happen in `ghc'.)
The `Makefile' in `ghc/compiler' is considered a leaf `Makefile' even though the `ghc/compiler' has sub-directories, because these sub-directories do not themselves have `Makefile' in them. They are just used to structure the collection of modules that make up `ghc', but all are managed by the single `Makefile' in `ghc/compiler'.
You will notice that `ghc/' also contains a directory `ghc/mk/'. It contains `ghc'-specific `Makefile' boilerplate code. More precisely: