- All build systems look like make.
And on a related, $DAYJOB-aggravating note:
- Tools always exit with non-zero status on failure.
- Tools never exit with non-zero status on success.
Aaaaaargh. I feel your pain.
Though I'm mostly irritated by those tools rather than the build systems which get that "wrong"...
- A build always runs on a single computer.
- There's always a human available to interact with the build system.
I'm inclined to say that the less scripting your build manager has to do the better - though a tool that doesn't require scripting in any situation sounds like an impossibility (and a tool that doesn't allow scripting sounds like it would eventually become painful).
Edited at 2012-12-07 03:21 am (UTC)
- Build steps are idempotent
- It can be known in advance how many times a particular build step should be executed
- Build steps do not modify the repository
- It is possible to determine whether the build will succeed
- It is possible to determine whether the build will even halt
*smacks forehead* - all good ones.
2012-12-07 04:12 am (UTC)
What is the point of this?
2012-12-07 01:31 pm (UTC)
Sorry that wasn't clear - I've added an explanation to the top of the post.
2012-12-07 09:15 am (UTC)
lets agree on this first
* Users will only will only use one specific compiler, library and flags, so you can hardcode them in your build scripts.
* Users will always agree with the location you want to install stuff to.
At my current job (HPC system administator at Ghent University) we have been building a lot of software which had these assumptions.
So to automate all of them we created a framework EasyBuild (http://hpcugent.github.com/easybuild/) which is a layer on top off all these build systems that tries to correct their mistakes (be the human to answer questions during the installation, patching makefiles/code to work with different compilers, install under a prefix and generate module files...) and automate the process of building the software.
This is not usefull for programmers, but for end users who want to install the software.
Edited at 2012-12-07 10:36 am (UTC)
2012-12-10 03:06 am (UTC)
build systems are a symptom of software languages that are not designed to build software systems
2013-09-11 04:40 am (UTC)
Greate post. Keep writing such kind of info on your blog.
Im really impressed by your blog.
Hello there, You have performed an incredible job. I'll certainly digg it and in my opinion recommend to
my friends. I am confident they will be benefited from this web site.
2013-10-15 11:38 am (UTC)
Thanks for sharing this great content, I really enjoyed the insign you bring to the topic, awesome stuff!
water systems (http://articlestwo.appspot.com/article/water-filtration-systems)
Javac is responsible for a lot of these. Why this may or may not be a Good Thing is a debate that could rage for years.
BTW, I'm working now with a horribly botched and broken build system that illustrates many of the listed bad assumptions, even though it's all C/C++ code. Surprisingly few of the problems are the fault of make itself.
2016-10-22 11:38 pm (UTC)
Fun with java
At a previous job many years ago, someone on the team took the time to write enough code to figure out what files would actually be output by the java compiler. It's really amazing, especially when you get into tricks such as having private classes hidden inside another class. The java compiler can produce some amazingly arbitrary output. It also has a habit of figuring out on its own if it wants to go build something else it happens to notice you need.
Try integrating that with make.
One more thing: there is a special place in hell for designers of products that can only be built or configured through a GUI.
2015-07-30 12:24 pm (UTC)
Falsehoods Programmers Believe
2018-01-21 01:35 pm (UTC)
> It's possible to determine the dependencies of a target without building it.
NixPkgs (a meta build-system) assumes this. Build systems that violate the rule include, oh, Gradle.
Makes Java packaging fun.
Java gleefully violates a lot of these assumptions, because why would you ever want to leave the Java ecosystem or integrate a Java component with code written in other languages?*
* I am in exactly this position at the moment :-(