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: