7 ms·

Falsehoods Programmers Believe About Build Systems (2012)

44 points by Something1234 9y ago

ioquatix 9y ago
As the author of a build system, which took 5 years to bring to completion, and is now used in commercial applications, I feel like this list is not that helpful. A modern build system does sacrifice generality in order to improve performance and simplicity. e.g. A build graph with cycles is non-deterministic, which is not a great property of a reliable and repeatable build tool. Most modern build tools will impose limitations to respect people's sanity, and I'm personally of the opinion that a build system should really expose high level rules for the most common tasks.
- clacke2 9y ago
  Is that https://github.com/kurocha/teapot https://github.com/kurocha/teapot ? ( https://teapot.nz/ https://teapot.nz/ ) The link on https://www.codeotaku.com/projects/index https://www.codeotaku.com/projects/index goes to some other place.
  - ioquatix 9y ago
    Yeah, it's teapot. Thanks, I fixed the link :)
- ahartmetz 9y ago
  I had similar thoughts about the acyclic graph "falsehood". Sure you can have a cyclic graph, but then your build system is going to be crap. The cycle has to be cut open by the build tool somehow, and builds may or may not work reliably as a result. It is better to avoid it.
Annatar 9y ago
Yet another Make hater; it's disgusting how many wannabe programmers misunderstand Make and then embark on some unholy crusade to kill or replace it. And then we end up with garbage, toy build systems limited by the programmer's understanding of what the build system should be capable of. After suffering through several of those toys (never by my own choice), I don't ever want to find myself in a situation like that again. Learn Make, truly learn and master it; don't just claim that you do! It functions the way it does for several reasons! Buy the O'Reilly book (on original Make, not the GNU Make version); go through the examples; UNDERSTAND THEM. And stop trying to build unnecessary replacements. There is enough garbage in the world of software already. Way too much in fact.
- dang 9y ago
  Indeed there is, but would you please not rant like this here? It's basically yelling at the reader instead of teaching us. The same goes for allcaps, which the site guidelines ask you not to use for emphasis: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
  - Annatar 9y ago
    Fine, I won't use CAPS any more. I'm not yelling at the reader, but at the author, and even in that I am way more restrained than I should have been. As for teaching, the teaching here is get the original Make book and go through the examples and understand them; there is no need for me to repeat what smarter and more learned men (namely the author of the Make book) have already written.
    - dang 9y ago
      The yelling affects everyone. When you post like that you're degrading the discussion for everyone and damaging the site. A few will always like it because they happen to share what you're annoyed at, or they're annoyed at something else and want a hit of rant energy. But the rest of us just cringe. HN threads are supposed to be for thoughtful conversation, not getting anger out. That doesn't mean people can't comment on something that angers them, but it takes work to do it in a way that's informative to others. Mere venting falls below the quality line.
      - Annatar 9y ago
        A thoughtful conversation requires a lot of insight and experience, both which appear to have taken a leave of absence. For a website aiming to provoke a thoughtful discussion, you (plural) sure like posting lots of inflammatory discussion material. Case in point: "death to Make!", and I quote the original article: It is accepted by all decent people that Make sucks and needs to die ... ... ... 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. Can you please provide some pointers on how I can effectively communicate a request to turn it down a couple of notches with respect to what appears to me to be a generation Y "hurt feelings" as evidenced by your response without hurting any feelings? Context: http://reason.com/archives/2017/10/26/the-fragile-generation http://reason.com/archives/2017/10/26/the-fragile-generation https://news.ycombinator.com/item?id=15993091 https://news.ycombinator.com/item?id=15993091 have I managed to make my point clear?
pebers 9y ago
Having spent some time working on build tools at my current company, I agree with some of those, and have repeated some others. That's pretty deliberate though, software is designed to meet a set of needs and for ours assumptions like "we never need to build on Windows" are fine. Making assumptions (some of which the author surprisingly doesn't capture well, like "file timestamps are monotonically increasing") which ultimately lead to incorrect builds are much less acceptable though.
mherrmann 9y ago
The first real build system I used was Maven - ie. huge declarative XML files for Java projects. Despite its boons for resolving dependencies, its declarative style and assumptions about build phases hit the limits on every project I used it for. I've come to see any build script as programming, however declarative. These days, I simply use Python scripts where separate functions describe what's to be done for each build target. Yes I have to write some basic functionality myself. But it's extremely flexible. YMMV for larger projects, but I am very happy with this.
- pjmlp 9y ago
  Maven was the fourth build system I got to use, and coming from Ant I kind of hated it, because the company was trying to shove our Ant workflows into Maven plugins, and the experience was quite bad. A few years later I embraced the declarative way, and changed my mind about it. In fact, I only use Gradle instead of Maven on Android projects, because Google forces me to do so. From my perspective many projects have issues with Maven, because it is easier to think imperative instead of declarative.
  - eitland 9y ago
    I also embraced maven. My rule of thumb is: if it doesn't "just work" with Maven and Netbeans I (or maybe sometimes someone else) is doing something wrong. (Although that "wrong" could be using a project that isn't ready for production use.) At one place we had this saying: I fixed more and more problems by removing my bosses code (i.e. falling back to the relatively sane defaults.)
    - tzahola 9y ago
      >I fixed more and more problems by removing my bosses code Very interesting phenomenon! Paraphrasing the Peter principle: incompetent people will be promoted until they can inflict the least harm. In some sense, this is a natural self-defense mechanism of an organization, like how the body encapsules benign tumors in connective tissue.
jchw 9y ago
These are not falsehoods. They're intentional limitations of the build system. A build system that attempts to avoid all of these is useless.
- sparkie 9y ago
  What use do we have for a build system that is less capable of the one that is very widely used, is available on nearly every platform, and on the ones where you're likely to need it most, it's usually already installed? The biggest falsehood is that programmers want such a build system. The chance of this system replacing Make is zero. The only way a build system is ever going to replace Make is by being 95% backward compatible with Make. If you're intentionally adding limitations to your build system such that most existing Makefiles can't be directly ported onto it, then your build system will never gain wide use beyond your niche cases.
moring 9y ago
The title says "build systems", but the author is actually speaking about direct replacements for 'make'. Many of the points listed deal with limitations of the compilers involved, and the inability of 'make' or its replacements to work around those limitations. It is, in my opinion, not useful to treat the compiler as something external to the "build system". For example, "It's possible to tell the compiler which file to write its output to." For a sufficiently advanced build system, of course this is possible. Just add a command-line option to the compiler that tells it to. What this article is actually saying is that writing a good build system is hard to impossible if you think that 'make' alone is the problem.
seba_dos1 9y ago
Waiting for "Falsehoods Programmers Believe About Falsehoods Programmers Believe" :P
draw_down 9y ago
What’s the point, here?
majewsky 9y ago
It does not inspire confidence when the first two bulletpoints are already redundant with each other. A tree is literally defined as an acyclic graph. > All the code you will ever need to compile is written in precisely one language. And that's why make is still popular. There are a ton of new-fangled build systems that only work with $language_du_jour. Particularly outrageous is Go, which is supposed to have its own builtin build system with "go install", but each vendoring tool has its own opinion about how to run a build, leading to unnecessary compilation instructions in a README that could just as well be thrown in a Makefile target. I always make sure that my programs build and install cleanly with make && make check && make install DESTDIR=... regardless of language.
- sparkie 9y ago
  I wouldn't say the first two are redundant. Trees are directed graphs where each node has at most one parent. Most build systems assume DAGs though, hence the second bullet point.

44 points by Something1234 9y ago

As the author of a build system, which took 5 years to bring to completion, and is now used in commercial applications, I feel like this list is not that helpful. A modern build system does sacrifice generality in order to improve performance and simplicity. e.g. A build graph with cycles is non-deterministic, which is not a great property of a reliable and repeatable build tool. Most modern build tools will impose limitations to respect people's sanity, and I'm personally of the opinion that a build system should really expose high level rules for the most common tasks.

clacke2 9y ago
Is that https://github.com/kurocha/teapot https://github.com/kurocha/teapot ? ( https://teapot.nz/ https://teapot.nz/ ) The link on https://www.codeotaku.com/projects/index https://www.codeotaku.com/projects/index goes to some other place.
- ioquatix 9y ago
  Yeah, it's teapot. Thanks, I fixed the link :)
ahartmetz 9y ago
I had similar thoughts about the acyclic graph "falsehood". Sure you can have a cyclic graph, but then your build system is going to be crap. The cycle has to be cut open by the build tool somehow, and builds may or may not work reliably as a result. It is better to avoid it.

Annatar 9y ago

Yet another Make hater; it's disgusting how many wannabe programmers misunderstand Make and then embark on some unholy crusade to kill or replace it. And then we end up with garbage, toy build systems limited by the programmer's understanding of what the build system should be capable of. After suffering through several of those toys (never by my own choice), I don't ever want to find myself in a situation like that again. Learn Make, truly learn and master it; don't just claim that you do! It functions the way it does for several reasons! Buy the O'Reilly book (on original Make, not the GNU Make version); go through the examples; UNDERSTAND THEM. And stop trying to build unnecessary replacements. There is enough garbage in the world of software already. Way too much in fact.

dang 9y ago
Indeed there is, but would you please not rant like this here? It's basically yelling at the reader instead of teaching us. The same goes for allcaps, which the site guidelines ask you not to use for emphasis: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
- Annatar 9y ago
  Fine, I won't use CAPS any more. I'm not yelling at the reader, but at the author, and even in that I am way more restrained than I should have been. As for teaching, the teaching here is get the original Make book and go through the examples and understand them; there is no need for me to repeat what smarter and more learned men (namely the author of the Make book) have already written.
  - dang 9y ago
    The yelling affects everyone. When you post like that you're degrading the discussion for everyone and damaging the site. A few will always like it because they happen to share what you're annoyed at, or they're annoyed at something else and want a hit of rant energy. But the rest of us just cringe. HN threads are supposed to be for thoughtful conversation, not getting anger out. That doesn't mean people can't comment on something that angers them, but it takes work to do it in a way that's informative to others. Mere venting falls below the quality line.
    - Annatar 9y ago
      A thoughtful conversation requires a lot of insight and experience, both which appear to have taken a leave of absence. For a website aiming to provoke a thoughtful discussion, you (plural) sure like posting lots of inflammatory discussion material. Case in point: "death to Make!", and I quote the original article: It is accepted by all decent people that Make sucks and needs to die ... ... ... 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. Can you please provide some pointers on how I can effectively communicate a request to turn it down a couple of notches with respect to what appears to me to be a generation Y "hurt feelings" as evidenced by your response without hurting any feelings? Context: http://reason.com/archives/2017/10/26/the-fragile-generation http://reason.com/archives/2017/10/26/the-fragile-generation https://news.ycombinator.com/item?id=15993091 https://news.ycombinator.com/item?id=15993091 have I managed to make my point clear?

pebers 9y ago

Having spent some time working on build tools at my current company, I agree with some of those, and have repeated some others. That's pretty deliberate though, software is designed to meet a set of needs and for ours assumptions like "we never need to build on Windows" are fine. Making assumptions (some of which the author surprisingly doesn't capture well, like "file timestamps are monotonically increasing") which ultimately lead to incorrect builds are much less acceptable though.

mherrmann 9y ago

The first real build system I used was Maven - ie. huge declarative XML files for Java projects. Despite its boons for resolving dependencies, its declarative style and assumptions about build phases hit the limits on every project I used it for. I've come to see any build script as programming, however declarative. These days, I simply use Python scripts where separate functions describe what's to be done for each build target. Yes I have to write some basic functionality myself. But it's extremely flexible. YMMV for larger projects, but I am very happy with this.

pjmlp 9y ago
Maven was the fourth build system I got to use, and coming from Ant I kind of hated it, because the company was trying to shove our Ant workflows into Maven plugins, and the experience was quite bad. A few years later I embraced the declarative way, and changed my mind about it. In fact, I only use Gradle instead of Maven on Android projects, because Google forces me to do so. From my perspective many projects have issues with Maven, because it is easier to think imperative instead of declarative.
- eitland 9y ago
  I also embraced maven. My rule of thumb is: if it doesn't "just work" with Maven and Netbeans I (or maybe sometimes someone else) is doing something wrong. (Although that "wrong" could be using a project that isn't ready for production use.) At one place we had this saying: I fixed more and more problems by removing my bosses code (i.e. falling back to the relatively sane defaults.)
  - tzahola 9y ago
    >I fixed more and more problems by removing my bosses code Very interesting phenomenon! Paraphrasing the Peter principle: incompetent people will be promoted until they can inflict the least harm. In some sense, this is a natural self-defense mechanism of an organization, like how the body encapsules benign tumors in connective tissue.

jchw 9y ago

These are not falsehoods. They're intentional limitations of the build system. A build system that attempts to avoid all of these is useless.

sparkie 9y ago
What use do we have for a build system that is less capable of the one that is very widely used, is available on nearly every platform, and on the ones where you're likely to need it most, it's usually already installed? The biggest falsehood is that programmers want such a build system. The chance of this system replacing Make is zero. The only way a build system is ever going to replace Make is by being 95% backward compatible with Make. If you're intentionally adding limitations to your build system such that most existing Makefiles can't be directly ported onto it, then your build system will never gain wide use beyond your niche cases.

moring 9y ago

The title says "build systems", but the author is actually speaking about direct replacements for 'make'. Many of the points listed deal with limitations of the compilers involved, and the inability of 'make' or its replacements to work around those limitations. It is, in my opinion, not useful to treat the compiler as something external to the "build system". For example, "It's possible to tell the compiler which file to write its output to." For a sufficiently advanced build system, of course this is possible. Just add a command-line option to the compiler that tells it to. What this article is actually saying is that writing a good build system is hard to impossible if you think that 'make' alone is the problem.

seba_dos1 9y ago

Waiting for "Falsehoods Programmers Believe About Falsehoods Programmers Believe" :P

draw_down 9y ago

What’s the point, here?

majewsky 9y ago

It does not inspire confidence when the first two bulletpoints are already redundant with each other. A tree is literally defined as an acyclic graph. > All the code you will ever need to compile is written in precisely one language. And that's why make is still popular. There are a ton of new-fangled build systems that only work with $language_du_jour. Particularly outrageous is Go, which is supposed to have its own builtin build system with "go install", but each vendoring tool has its own opinion about how to run a build, leading to unnecessary compilation instructions in a README that could just as well be thrown in a Makefile target. I always make sure that my programs build and install cleanly with make && make check && make install DESTDIR=... regardless of language.

sparkie 9y ago
I wouldn't say the first two are redundant. Trees are directed graphs where each node has at most one parent. Most build systems assume DAGs though, hence the second bullet point.