V
Comparing the potential benefits of system changes that help and the detriments of changes made for the sake of change.
I maintain a legacy system at work that uses Makefiles for building the code. Recently my company switched to a different system—SCons—for doing software builds and now I’m being asked to update our legacy code to build with this system. Personally, I don’t see that we will get any benefit switching a legacy system’s build strategy, but it’s an order from management so I will likely have no choice. Why would anyone bother to switch a working build system to a newer one? Are build systems really that different? Is there really any innovation here that could matter?
illustration by ryan alexanDer
Innovation, as someone should have said, is in the eye, or perhaps hands, of the beholder. KV rarely condones change for its own sake: the change has to have some appreciable benefit to those who are working with the system. As this relates to build systems, there are few things more important to a programmer’s work flo w and therefore productivity than how their system is built. A poorly implemented build system will impede progress and lead to wasteful programmer downtime, mostly made up of programmers playing games in the hallway, buying questionable items on the Web, and learning yo-yo tricks. All fine pursuits of course—I learned at least five yo-yo tricks on one job when it took 20 minutes to build a piece of software, and the build locked up the
machine we all used for our work. Of course such crippling times are in the past now, with the advent of speedy CPUs, memory, and disks there is no longer any wasted programmer time, and we can all depend on a quick com-
pile/link phase. Uh, perhaps not.
There are several reasons why people switch build systems. I think the most common one is that people hate and fear Makefiles. Other than the mis-named autotools there is probably no
APriL 2009 | voL. 52 | no. 4 | communicAtionS of the Acm
25
References:
Archives