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.
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.
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.
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.
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.
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:
> A thoughtful conversation requires a lot of insight and experience, both which appear to have taken a leave of absence
Yes, of course that's true, but all you've done is state the default condition of an internet forum. The whole idea of HN is to try to rise above that sludgey default, at least in part. It's a constant struggle because there's a constant downward pull, so we need users like you to understand the intention and post at a higher quality level.
I'm sure you wouldn't litter in a city park, even if there was already some litter there. You might even pick some of the litter up, if you were feeling like a good citizen that day.
I’ve already prescribed the reading material and the mastery plan; am I understanding correctly that you’d also like me to write tutorials as comments in order to up the quality? How could I have worded my response differently? A subject like Make, being such a flexible, powerful tool takes years to master, hence the Windows / generation Y / Stackoverflow crowd backlash.
Did you read some of the responses like
“You do realise that it's quite a request to make? Getting a specific book and going trough it, until you reach enlightenment? Personally I'd say that any build system requiring me to read a full book to understand it has already failed to fulfil the requirements I have. Any time I don't have to spend fiddling with or learning about build systems is time well spent in my world.”
These guys deserve far more than just yelling at them. The damage they cause to our industry and our work conditions because of their attitude is enormous, enough to want to leave the industry and never touch it again (I’ve been seriously considering a career switch after 30+ years of working with and on software and hardware). Instead of making progress, we’re regressing; for every student that studied under me, ten such guys crop up because our industry is perceived to pay well and provide job security, both intrinsically wrong motives to be in it. And they won’t listen, they think they know exactly what they’re talking about.
You do realise that it's quite a request to make? Getting a specific book and going trough it, until you reach enlightenment? Personally I'd say that any build system requiring me to read a full book to understand it has already failed to fulfil the requirements I have. Any time I don't have to spend fiddling with or learning about build systems is time well spent in my world.
Do you want to master it or not? Your choice, but you won't master it via "Stack Overflow".
What would you have done if you had grown up at Bell Labs, refused to read manual pages?
Is it worth using shitty software or putting up with shitty software or reinventing the wheel over and over and over again just because you feel like mastering something is too much work? If it is... it's just one more reason for me to exit this industry, for I do not want to keep such company.
Ok, just wondering, why would I get down-voted for this? I must have misunderstood the idea about down-voting, to me it looks like people are just expressing disagreement, I thought it was about discouraging impolite discussion?
From that comment it seems that the down votes are about expressing anger that people like me have the opinion that build systems are a second order priority.
I can't see how the comment itself should not be allowed as part of a discussion about the level of reading should be required to participate in a conversation about build systems?
The comment isn’t disallowed; the downvote count just tells you how many people disagree with your statement and think you’re wrong about what you’re saying.
By the way, Make is so powerful that not only can it be used as a build engine, but for day to day system administration, web development and general task automation as well.
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.
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.
Paraphrasing the well-known LISP aphorism: Every sufficiently complex build system will have an incomplete, buggy and slow implementation of Make within.
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.
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.
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.
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.)
Besides several other differences between a Make build and a Python script, which your reply ignores, I do much prefer writing in Python over shell scripts.
Interesting. But not Turing-complete? So if I run into a case it doesn't cover (which I will), I have to drop to another language/tech. Then why not go with that language in the first place?
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.
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.
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
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.
39 comments
[ 2.4 ms ] story [ 90.0 ms ] threadA 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.
The link on https://www.codeotaku.com/projects/index goes to some other place.
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.
The same goes for allcaps, which the site guidelines ask you not to use for emphasis: https://news.ycombinator.com/newsguidelines.html.
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.
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.
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
https://news.ycombinator.com/item?id=15993091
have I managed to make my point clear?
Yes, of course that's true, but all you've done is state the default condition of an internet forum. The whole idea of HN is to try to rise above that sludgey default, at least in part. It's a constant struggle because there's a constant downward pull, so we need users like you to understand the intention and post at a higher quality level.
I'm sure you wouldn't litter in a city park, even if there was already some litter there. You might even pick some of the litter up, if you were feeling like a good citizen that day.
If you'd take a look at https://news.ycombinator.com/newsguidelines.html and https://news.ycombinator.com/newswelcome.html and http://www.paulgraham.com/hackernews.html, I'm sure you'll get the idea.
Did you read some of the responses like
“You do realise that it's quite a request to make? Getting a specific book and going trough it, until you reach enlightenment? Personally I'd say that any build system requiring me to read a full book to understand it has already failed to fulfil the requirements I have. Any time I don't have to spend fiddling with or learning about build systems is time well spent in my world.”
These guys deserve far more than just yelling at them. The damage they cause to our industry and our work conditions because of their attitude is enormous, enough to want to leave the industry and never touch it again (I’ve been seriously considering a career switch after 30+ years of working with and on software and hardware). Instead of making progress, we’re regressing; for every student that studied under me, ten such guys crop up because our industry is perceived to pay well and provide job security, both intrinsically wrong motives to be in it. And they won’t listen, they think they know exactly what they’re talking about.
What would you have done if you had grown up at Bell Labs, refused to read manual pages?
Is it worth using shitty software or putting up with shitty software or reinventing the wheel over and over and over again just because you feel like mastering something is too much work? If it is... it's just one more reason for me to exit this industry, for I do not want to keep such company.
I can't see how the comment itself should not be allowed as part of a discussion about the level of reading should be required to participate in a conversation about build systems?
By the way, Make is so powerful that not only can it be used as a build engine, but for day to day system administration, web development and general task automation as well.
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.
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.
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.
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.)
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.
I've seen consultants that would create crazier code.
He just wasn't used to Maven conventions.
Oh, and we both laughed :-)
Congratulations, you're reimplemented make(1), except with Python instead of shell scripts.
http://mesonbuild.com/
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.
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.
> 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
regardless of language.