Version Control

This month we would like to turn the spotlight on to that oft neglected and under-valued specimen the build engineer. In the physical world, the term “building” has traditionally inspired status and respect. We just have to think of structures from the pyramids to medieval cathedrals to skyscrapers.

How do you build? How do you select the source code files to include in a build? How do
you identify the revisions, or versions, of the files to include a build? Do you build from the tip revisions in your version control system or do you build by selecting a specific revision of every source code file? Do members of the development team specify the changes to include in each build or do you sweep in all changes implemented at the time of the build? When do you build from revisions in the mainline of the version control system? When do you build from revisions in a branch?

The software development business, once the domain of a few advanced technology companies, is now pervasive. Why? Because software is less costly and easier to modify than hardware. At first glance this is obvious; building a software telephone switch is a lot less costly than the hardware equivalent. Looking more closely, though, software products have far more features and, therefore, are more complex than hardware products. Software is easier to change, but this just adds to the level of complexity, especially on the management side. Software allows us to build products that are more complex.

The $(eval) function was introduced in GNU Make 3.80 but was a little buggy, 3.81 has fixed those bugs in $(eval) is ready for prime time.  $(eval)'s argument is expanded and then parsed as if it were part of a Makefile.