Parallel build execution is a popular technique for reducing software build length, and for good reason. Today, multi-core computers are common, particularly for software developers, so there’s horsepower to spare, and it seems seductively easy to dabble with parallel builds: just slap a “-j” onto your make command-line,sit back and enjoy the benefits of a build that’s 2, 3 or 4 times faster than it used to be.

Unfortunately, with this simple approach you are guaranteed to run into parallel build problems. There will be incomplete dependencies in your makefiles, tools that don’t adequately uniquify their temp file names, and a host of other things that can introduce race conditions into your parallel build. Sometimes everything will work perfectly, and you get a nice, fast, correct build. Other times, the build blows up in spectacular fashion. Then there are the builds that appear to succeed, but in fact generate incorrect outputs, because a command ran too early and used files generated in a previous build instead of the current build.

These are the problems Electric Make, from Electric Cloud, was designed to solve, producing fast, reliable parallel builds, regardless of how (im)perfect your makefiles and tools are. If the build works serially, it will work with Electric Make, but faster.

This paper will explain how Electric Make (emake) ensures correct builds, including the inner workings of basic conflict detection and exceptions to the algorithm that enable emake to execute builds faster than any other parallel build technology.