This well-written and insightful book contains everything you ever wanted to know (and then some) about how to put programs together to build a software product. Smith, a build guru, urges other gurus, managers, and developers to read his book. Maybe gurus will plow through it; I doubt others will. Still, there is much to be learned from reading only the first third of the book.

Software build technology is a sub-specialty of software configuration management, and some software shops use dedicated people in their system build operation. This function can be a bottleneck in product development. However, with administrative support for change control and for tracking problem reports, it becomes integral to the process of building software projects: an in-line job with all of the attention such functions deserve. Those that distract their application developers with backwater build tasks too often experience project crises from product build delays or the loss of configuration management.

I am disappointed that the book does not place the important build process within the overall software development process. The book is aimed at those charged with building a system from the many components that comprise industrial-strength software systems. I call this the software manufacturing process. The book is detailed; managers and application developers will benefit from the preface and build “basics” sections, but will find two-thirds of the book too detailed for their needs.

The book consists of 19 chapters, split into three parts. The first part of the book has 100 pages that explain the basics of the build system concept. Topics include: the generic architecture of the build system; the use of the makefile software utility; the runtime view of a program; file types; and compilation tools for C, C++, Java, and C#. All software professionals should study this part of the book.

The 200 pages in the second part of the book provide details of the build tools. Most people will not need this knowledge--the information is at a level of detail appropriate for build specialists who build tools for making the build.

The third part of the book contains advanced topics that will prepare a software shop for building effective software products. I especially recommend chapter 11, which covers dependencies. The remaining chapters are more appropriate for those who specialize in programming tools for future build systems. I liked chapter 17’s material for reducing build complexity. Chapter 19 goes beyond features to explain how to address the architectural issues of making builds faster.

The aim of this book is to explain and characterize the principles underlying the build system. Though it achieves this goal, it is not a handbook on how to build a software product. The book shows that our industry is maturing. It is well written, with many examples and clearly explained code snippets, and is appropriate for undergraduate and graduate courses covering the process and technology of building software systems.

The make tool was invented as part of the world-renowned Unix effort by Bell Labs. Even though Smith mentions Unix in three places, he does not point out that make and new make emerged from the Unix Bell Labs computer science culture that revolutionized software development in the 1980s.

I am concerned that few others will find the book as compelling as I did. My copy is a welcome addition to my personal library, but it may not be to yours.