
Falsehoods Programmers Believe About Build Systems (2012) - Something1234
https://pozorvlak.livejournal.com/174763.html
======
ioquatix
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
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
Yeah, it's teapot. Thanks, I fixed the link :)

------
mherrmann
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
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
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
>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.

~~~
eitland
FWIW: I wasn't the one downvoting.

~~~
tzahola
Thanks man, here's an upvote for letting me know :3

------
pebers
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.

------
jchw
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
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.

------
majewsky
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
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.

------
moring
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
Waiting for "Falsehoods Programmers Believe About Falsehoods Programmers
Believe" :P

------
Annatar
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.

~~~
stinos
You seem to imply that once you understand make, you won't dislike it anymore
or don't want to see it replaced or will stop criticizing it. For one thing,
the better you understand a tool the more correct your critique on it can be.

I learned quite a bit of make and msbuild and cmake (yeah it's not a true
build system but that doesn't matter here) at practically the same time. I
can't say I really really like any of those. I also don't truly hate them. Yet
one thing is clear: I understand how they work and how they were intended to
be used. But none of them are _the_ perfect answer.

No matter how well e.g. make works, that doesn't somehow magically make it's
sometimes awkward 'let's cram as much meaning as possible into as little
characters as possible like we're still programming on 75 character terminals'
syntax good. Just like msbuild's overly verbose xml is no better. Though it
still is more readable to me.

So just like you understand make, you should try to understand why people
build replacements. If you can't, you're just blind for the downsides of your
favourite build tool.

~~~
Annatar
_You seem to imply that once you understand make, you won 't dislike it
anymore or don't want to see it replaced or will stop criticizing it._

Criticising it?!? Make is an ingenious tool! It's a phenomenal tool, if one
just looks at the flexibility of it, never mind all the super useful built in
rules that it comes with out of the box!

 _For one thing, the better you understand a tool the more correct your
critique on it can be._

Correct, but therein lies the rub: the author of the essay clearly does not
command understanding of Make, and even worse, he believes he does. Worst of
all, he is not alone: this Make hate pops up every so often here, one can
clearly see who is learning build systems and who eventually hit Make (all
build systems' roads lead to Make sooner or later) and just didn't get it. By
my own experience, it's mostly Windows users turned GNU/Linux.

I would be curious to learn whether I'm correct in the case of the author of
the essay, really curious.

