What is a "make engine"?

Like an automobile engine, a make engine is the collection of complex moving parts that are hidden from the operator. An engine is an imperative component if you want your vehicle to perform in an efficient manner; likewise, a make engine can make the execution of your software more efficient. The engine represents the nucleus of the functioning product. This nucleus is where the moving parts are linked (compile pun intended) together and translated into an operator-understandable instrument. That's the simple metaphor; the more realistic definition would dwell on the intricacies of the processes surrounding the integration of those moving components. But who needs a definition that would require that much verbosity? A mechanic, maybe ... oops, I mean a build manager ...

Hidden? Where is it hidden?

We like to hide our make engine in a single make directory or folder. If you've ever been exposed to building a software application (particularly on a Unix platform), then you've probably heard of Make and Makefiles (a discussion slightly out of the scope of this forum). It is the premises of Make that we always seem to return to, and the reason that we put our make engine in a make directory. We haven't rewritten the Make utility; on the contrary, we utilize Make and other make-like utilities. The fact that we choose to implement this engine from a single directory is for ease of maintenance.

Mechanic? Build manager? Now you're going to tell me I need to be ASE certified to maintain this thing!

Not really. But we will tell you that our make engine is made up of three logical pieces. Each requires some varying degree of understanding in order to provide maintenance. For those of you who always got sent to the car parts store to purchase parts for Dad, we have a component file which simply identifies those obvious elements. For those of you who like to change your own oil, we have an environment file which simply defines some of the less obvious variables in the procedures. Finally, for those of you who can rebuild that transmission, we have the rules file which not-so-simply integrates the component and environment files while establishing all the processes involved.

Enough with the automotive metaphors! I know how to invoke the compiler and create my "hello world" executable.

Yeah, but what if you had 20 executables to maintain ... and sometimes you need to build only the five that print "hello" statements ... and sometimes you need to build only the five that print "goodbye" statements ... and sometimes you have to build them all and generate documentation for each one ... and then package them up and install them in a testing environment ... but four of them are a different 3GL ... and some of them are legacy requiring a different compiler ... etc. Can you see the possibilities? Potentially numerous components and numerous procedures; your one compiler invocation can not handle all those scenarios. Our make engine can!

The Three Logical Pieces of the make engine

You've already been introduced to the component, environment, and rules files, so let's discuss them in a little more detail.

1. Component file: Maintained by the developers; this file includes a list of targets and the source files that comprise each target. This file will be altered as new source files are created and obsolete source files are deleted.
2. Environment file: Maintained by the technical lead; this file includes command definitions, command options definitions, and various other related environment settings. To alter this file, you should possess an understanding of the tools required to build the product and how to run those tools within the scope of the product's requirements specification.
3. Rules file: Maintained by the build manager; this file contains the procedural logistics for building the targets from the corresponding source files. In the world of Make, this means building a dependency tree and enforcing or using those dependencies for efficient incremental builds.

The Benefits of the Make Engine

A well-designed make engine provides many benefits that translate into cost and schedule reduction. The following characteristics are typical of an efficient make engine:

• Collective build process for distributed (and potentially unique) components
• Standardized repeatable build procedures (independent of your role in the software life cycle)
• Self-reporting (in a manner that's readable by minds of varying technical degrees)
• Platform-nonspecific
• User-friendly interface
• Easy to maintain

When a make engine displays these traits, periodic automated unattended builds are your reward. At SCM Labs, we've implemented automated procedures that will, with a single command, a) cut a release of software in the repository; b) generate all targets (executable, document, or otherwise); c) update a database of corresponding change request records; d) prepare an installation snapshot; and e) mail the results (with success/failure status) to the interested parties.