Build system are often viewed as merely a script to compile the code. However there are much more to it. The book by Peter Smith: “Software Build Systems: Principles and Experience by Peter Smith” fills the gap. Below is the review I put onto amazon.
5-star A Gap-Filling Book for Software Developers Too, November 8, 2011
A Gap-Filling Book for Software Developers Too
Build system are often viewed as merely a script to compile the code. However there are much more to it. Read this book you’ll find out. As an editorial review says, this book is also for developers in addition to build engineers.
As the book starts with, a survey showed that it is common developers losing 20~30% productivity due to build related problems. My personal estimate, at one of my previous work we spent more than 30% of time dealing with build breakages. Sometimes the problems are caused by the build system itself, some other times they are due to misuse of the system. It’s worth for developers to learn the build system thus to avoid messing up with the build system.
For large software it is very difficult to figure out the dependencies among the components. To my view, if it is a C program, the only place the complete dependency information can be found is in the build system. Figuring out dependencies helps developers to better design/code/debug their software. To do so you’ll have to know about the build system, or you may even need to fix the build system so you can get the information dumped for you.
I use code generation in my coding practice so that I can manage more logic in code and avoid tedious repetitive work [see Martin Fowler’s DSL book Domain-Specific Languages (Addison-Wesley Signature Series (Fowler)) for more on this topic]. I also generate tests from the source code. To generate code the triggers have to be incorporated into the build system. Had I read this book I would have done my work more effectively.
[Update 2011-11-9]Even if you are on a small project, often the code needs to be configured and customized for different versions and platforms, or products. The conditional customization part, can often either be in the source code like by C ifdef primitives or in the makefiles. Knowing the build system gives the developers an alternative way of thinking where it is best to put those conditional parts. Sometimes we track the definition of a predefined macro, and it may end up in a makefile. This is the time you have to understand the makefile to know how exactly that macro is defined and used. For this reason, I would say the build system is part of the source code implementation, knowing the build system is essential to the developers.
I give this book a 5-star because in some sense it fills the gap between developers and build engineers, not that this book is perfect.I give this book a 5-star rating because in some sense it fills the gap between developers and build engineers, and it brings an often ignored area to attention of developers. Not that this book is perfect. [Update 2011-11-11]
It does not cover Maven, Autotools (autoconf, automake, libtool), and Tundra, among some other build tools. You may also read the slashdot book review [http://books.slashdot.org/story/11/06/29/1312251/book-review-software-build-systems] for how some insightful people say about this book and relevant topics the relevant topics.
(The review was posted to amazon.com. Follow the link, the book reviewed is on the right side of the page).