PEPeaker·Sep 1, 2015
The problem with `make` (and all build systems that generate `Makefiles` for `make`) is both flexibility and correctness. Correctness problems:
* Make cannot correctly specify file system state dependencies (like inexistence of files, such as include files in include paths prior to the found location).
* Make doesn't protect against accidental edits of source code while it is being built, poisoning the result files. When you try to run "make" again, it will say nothing is to be done, but the result file [with its newer mtime] can actually be based the pre-save source file.
* Make uses < and > for mtime checks (not just ==) and that is incorrect on some operating systems (e.g: Windows).
* Make offers no practical way to track or enforce system-level dependency changes.
* Easily miss stderr printouts from compilers/etc, if you missed them
Read the rest
at the first time around (losing mainly gcc/clang warnings)
The "solution" is almost always to "make clean" whenever voodoo bugs are encountered, anything system-level is changed, etc. This is terrible if you expect correctness from your tools.
Flexibility-wise, make is also awful, due to one huge problem:
Make requires the dependency graph to be fully specified, including all transitive dependencies. This makes code generation a near impossibility -- since you often need to scan the generated code to figure out its dependencies.
IOW: Make is a "two-phase" build system, where we really want an "N-phase" build system that interleaves building with dependency scanning/discovery.
Also, this is taken for granted, but it is major: Make requires error-prone specification of all file dependencies. This is impractical to do correctly in large, complex projects. Every script being run may have tons of transitive dependencies that are very hard to specify. Any mistake will usually go unnoticed, until you hit a "voodoo bug" and just "make clean".
Additionally, make doesn't support any form of advanced caching of previous build results.
---
All these problems, and more, made me decide to create my own build system for our complex C project: buildsome[1].
It uses file system hooking to provide both correctness (no more missed input dependencies!) and simplicity (no need to specify each and every transitive dependency, they can be automatically discovered).
It checks input files for changes after the build commands (to avoid output file poisoning). It remembers stderr and re-prints it. It supports N-phase builds. And more.
[1] https://github.com/ElastiLotem/buildsome