MakefileOverview

The Makefile system is constructed by a combination of elements:

• An environment script that sets up environment variables for make to use for its anchor locations.
• A set of included makefiles that define the macros for the build rules.
• A rule file that handles sub-directories for build recursion.

The top-level Makefile is in the project directory, and is used to launch the auto-build. It consists of only a list of directories to build, and an included .mk file sets up the recursion targets. It assumes that there are no actual targets to build (actual code, that is).

Each application and library directory has its own Makefile, with a few assumptions:

• C/C++ binaries and libraries assume that there are no sub-directories to do builds in. This is contrary to some kinds of C projects I have seen, where libraries for applications are built inside the application code directory. This is a non-globalized practice, and leads to a tangle of include paths and such which should be avoided. The C/C++ application and library directories are flat, to promote maximum sharing of code that is really library code, and to minimize sharing of code that is really specific application code. The assumption is that code will migrate out of applications into libraries on a regular basis, so get used to it!
• Java Applications and Jar Applications also assume that there is a flat structure for the application itself.
• Java Libraries and Jar Libraries provide for full recursion by way of macros that identify sub-directories that should be built before the directory and after the directory code is built. This provides for java packages and sub-packages to be organized according to the directory structure.
• Html and Jsp targets provide for sub-directory builds as well, but there is no real compilation done. The build just copies the files to another directory tree so that ongoing work can be done on the development files, and a 'make install' will copy the files when they look good enough to put into the 'built' area. This is good for having a reference copy of the older files in the 'built' area, with another copy being the 'work' copy. This also facilitates the use of an 'install' target for the main build area so that the auto build can publish files that are then picked up and moved to the final drop site for transition into QA or production.
• Perl Applications assume a flat directory structure.
• Perl Libraries assume a recursive build environment.
• Shell applications assume a flat directory structure.
• Python and Tcl may be added in the future it I get adventurous. It should be easy to provide for that based on examples.

This comprehensive structure provides a top-down recursive system that can be used to schedule automatic builds for the entire source tree. The objective is to provide a fully mixed environment (in terms of language), but a subdivided environment based on the style of build product. This largely breaks down into libraries and applications. Different applications run in different contexts, but the code is usually not shared. If code is shared, then it is a library. It is better to not let applications slop all over each other, because the cross-directory references lead to hidden dependencies that are hard to manage across a build tree. If the coding is shared, then the problem is magnified several-fold, and it is just better to create real libraries for anything that is shared. This leads to another problem, which is the design of namespaces and packages. It is my firm belief that it is better to put in the effort there, since it will lead to better library cohesiveness. It is less convenient, but worth it if you intend to have a long-run scenario on your hands.