Falsehoods programmers believe about build systems

[pozorvlak]

Inspired by Falsehoods Programmers Believe About Names, Falsehoods Programmers Believe About Time, and far, far too much time spent fighting autotools. Thanks to Aaron Crane, totherme and zeecat for their comments on earlier versions.

It is accepted by all decent people that Make sucks and needs to die, and that autotools needs to be shot, decapitated, staked through the heart and finally buried at a crossroads at midnight in a coffin full of millet. Hence, there are approximately a million and seven tools that aim to replace Make and/or autotools. Unfortunately, all of the Make-replacements I am aware of copy one or more of Make's mistakes, and many of them make new and exciting mistakes of their own.

I want to see an end to Make in my lifetime. As a service to the Make-replacement community, therefore, I present the following list of tempting but incorrect assumptions various build tools make about building software.

All of the following are wrong:

1. Build graphs are trees.
2. Build graphs are acyclic.
3. Every build step updates at most one file.
4. Every build step updates at least one file.
5. Compilers will always modify the timestamps on every file they are expected to output.
6. It's possible to tell the compiler which file to write its output to.
7. It's possible to tell the compiler which directory to write its output to.
8. It's possible to predict in advance which files the compiler will update.
9. It's possible to narrow down the set of possibly-updated files to a small hand-enumerated set.
10. It's possible to determine the dependencies of a target without building it.
11. Targets do not depend on the rules used to build them.
12. Targets depend on every rule in the whole build system.
13. Detecting changes via file hashes is always the right thing.
14. Detecting changes via file hashes is never the right thing.
15. Nobody will ever want to rebuild a subset of the available dirty targets.
16. People will only want to build software on Linux.
17. People will only want to build software on a Unix derivative.
18. Nobody will want to build software on Windows.
19. People will only want to build software on Windows.
    (Thanks to David MacIver for spotting this omission.)
20. Nobody will want to build on a system without strace or some equivalent.
21. stat is slow on modern filesystems.
22. Non-experts can reliably write portable shell script.
23. Your build tool is a great opportunity to invent a whole new language.
24. Said language does not need to be a full-featured programming language.
25. In particular, said language does not need a module system more sophisticated than #include.
26. Said language should be based on textual expansion.
27. Adding an Nth layer of textual expansion will fix the problems of the preceding N-1 layers.
28. Single-character magic variables are a good idea in a language that most programmers will rarely use.
29. System libraries and globally-installed tools never change.
30. Version numbers of system libraries and globally-installed tools only ever increase.
31. It's totally OK to spend over four hours calculating how much of a 25-minute build you should do.
32. All the code you will ever need to compile is written in precisely one language.
33. Everything lives in a single repository.
34. Files only ever get updated with timestamps by a single machine.
35. Version control systems will always update the timestamp on a file.
36. Version control systems will never update the timestamp on a file.
37. Version control systems will never change the time to one earlier than the previous timestamp.
38. Programmers don't want a system for writing build scripts; they want a system for writing systems that write build scripts.

[Exercise for the reader: which build tools make which assumptions, and which compilers violate them?]