Go to the first, previous, next, last section, table of contents.

A larger project

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:



      ...source files for documentation...

      ...source files for driver...

      parser/...source files for parser...
      renamer/...source files for renamer...
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:

So these two files are the place to look for `ghc'-wide customisation of the standard boilerplate.

Go to the first, previous, next, last section, table of contents.