Log in

No account? Create an account
Falsehoods programmers believe about build systems - Beware of the Train — LiveJournal [entries|archive|friends|userinfo]

[ website | My Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

[Links:| My moblog Hypothetical, the place to be My (fairly feeble) website ]

Falsehoods programmers believe about build systems [Dec. 6th, 2012|09:45 pm]
[Tags|, , , , ]

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?]


From: (Anonymous)
2012-12-07 04:12 am (UTC)
What is the point of this?
(Reply) (Thread)
From: (Anonymous)
2012-12-07 01:31 pm (UTC)
(Reply) (Parent) (Thread)
[User Picture]From: pozorvlak
2012-12-08 11:46 am (UTC)
Sorry that wasn't clear - I've added an explanation to the top of the post.
(Reply) (Parent) (Thread)
From: (Anonymous)
2018-11-30 11:53 am (UTC)

It's an exercise in self-importance and stupidity.

This guy will never create a build system. Most of these assumptions are not in fact made, and the ones are made are for pragmatic reasons. I'm thankful for systems like make and cargo, and that I've never had to work with this guy or use any of his software.
(Reply) (Parent) (Thread)
[User Picture]From: pozorvlak
2018-11-30 04:59 pm (UTC)

Re: It's an exercise in self-importance and stupidity.

I currently have neither plans nor time to create a build system, yes - and I'd be reluctant to do so unless I could come up with a model that solves all the problems listed above! Of the systems I know about, tup and waf look most promising.

Not every build system makes all the assumptions listed above (some are contradictory, so that would be hard), but I've seen every assumption above made at least once, and every system I know about (which is by no means all of the ones that exist; check out Wikipedia's list of build automation software) makes at least one of those assumptions. Some of them are pretty subtle, and only become apparent with painful experience. I've been meaning for years to produce an expanded version of this list, with "systems that make this assumption" and "tools or projects that violate this assumption" entries.

And I too am grateful for the existence of build systems! Compared to the alternative of hand-rolled build scripts with no dependency-tracking, they're an enormous boon. But I've also spent many frustrating hours fighting with their limitations, which led to this list. To be clear, I don't want Make to just go away, I want it to be replaced with something much better - and I believe this is possible, but not if people keep making the same mistakes.

Edited at 2018-11-30 05:00 pm (UTC)
(Reply) (Parent) (Thread)
From: (Anonymous)
2018-12-02 03:15 pm (UTC)

Re: It's an exercise in self-importance and stupidity.

You managed to sound both an idiot and an asshole in not too many words, congratulations.
(Reply) (Parent) (Thread)