To unify or not to unify: a case study on unified builds (in WebKit)

Native Build System for Unity Builds with Sophisticated Bundle Strategies

“…However, the build times for large C++ projects have become unacceptably long [11]- [14]. System software has continuously and rapidly evolved, and code sizes have reached thousands of source files and millions of lines of code (LOC).…”

“…The build times of incremental builds are also problematic because source-code modifications are no longer small in large open-source projects. For example, a recent study [14] has pointed out that build tasks taking more than 15 minutes were submitted to build bots of WebKit almost every day from March 17 and August 3 in 2018. In such build tasks, 1,030 source files were recompiled on average.…”

“…For example, when one source file is to be updated, the build system recompiles only that source file; it does not recompile any other source files. However, since the code size of software projects has increased, the full build times and even incremental build times have become longer and problematic [11]- [14]. Full builds mean building the whole of target projects, in which many source files are compiled.…”

“…However, unity builds negatively impact incremental builds [14]. They enlarge each compiler task by bundling multiple source files.…”

“…However, this simple strategy ignores characteristics of the source files to be bundled (e.g., which header files are #included in the source files) so that undesired source files are likely to be bundled together. In our previous study [14], we investigated the unity builds of the WebKit and revealed some better bundle strategies that improve both the full-build performance and the incremental-build performance in unity builds.…”