Build systems such as Make, CMake and the Zig build system turn source code into working programs. They compile source files in the correct order, link objects correctly, provide reproducible rebuilds and handle tests, documentation and platform-specific compilation requirements.
To do any of that, they have to be told what depends on what. According to Yuta Saito, Kazunori Sakamoto and Hironori Washizaki of Waseda University, managing those declarations remains a challenge, and accounts for more than half of all build errors in large projects.
Checking the declarations against reality is possible in principle: a tracing tool can watch which files a build actually opens. The obstacle has been cost. Tools built on ptrace suspend the process and switch context for every system call, which is slow enough that the check does not get run routinely.
The researchers' tool, mkcheck2, moves the tracing into the kernel using extended Berkeley Packet Filter, or eBPF, which allows sandboxed programs to run in kernel space and is already used for efficiency gains in services such as Meta's Strobelight.
"By executing tracing code directly in kernel space, we can monitor build processes with minimal impact on build performance," the authors write. "Unlike ptrace, which requires process suspension and context switches for each system call, our eBPF-based approach provides non-invasive tracing by operating entirely within the kernel."
The figures appear in a paper titled "Efficient Build Dependency Verification Using eBPF and Incremental Analysis", published in the Proceedings of the 2026 IEEE/ACM 48th International Conference on Software Engineering.
"Our evaluation on a diverse set of open-source projects demonstrates that mkcheck2 reduces the overhead of dependency error detection by up to 99.7 percent compared to existing ptrace-based approaches while maintaining detection accuracy," the authors write. "Across the entire 300-project Make corpus, the incremental analysis technique lowers the mean analysis time per commit from 1267.49 seconds to just 23.56 seconds, making continuous dependency verification practical in real-world development environments."
That is roughly 54 times faster per commit: from about 21 minutes to under half a minute.
The authors also list what the approach cannot do. The eBPF tracing is Linux-specific, so build systems on other operating systems can expect no gain. Some kinds of redundant dependency, access to memory-mapped regions, visibility into dynamically loaded libraries, network dependencies and distributed build systems all remain difficult.
It is worth being clear about what the check establishes, because it is not really a fact about speed. A build file is a claim. It states which inputs a target requires. Until somebody traces the system calls, that claim has been accepted on the author's word.
This newspaper has been reading the figure the other way round. For as long as verification cost 21 minutes a commit, the declared dependency list was not a description of the build. It was an opinion about the build, held confidently and at scale.
The opinion has now been priced at 23.56 seconds, which is cheap enough that holding it becomes a choice. Our analysts consider this the real result: more than half of the build errors in large projects were disagreements between a program and its own paperwork.
The escalation is uncomfortable but follows directly. Every declared dependency that has never been traced is unverified. Software that builds correctly is not thereby correct about why it builds correctly. It has merely not yet been contradicted.
The Department of Unnecessary Research has extended the method to the remaining cases. Network dependencies, dynamically loaded libraries and distributed builds are precisely the parts of the system that cannot be traced, and are therefore the parts in which confidence is highest.
The tool does not fix a single build. It establishes what the builds were doing while everybody assumed they knew.
On Linux, at least. Elsewhere the paperwork stands.