Falsehoods Programmers Believe About Build Systems (2012)
pozorvlak.livejournal.com
pozorvlak.livejournal.com
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.
The link on https://www.codeotaku.com/projects/index goes to some other place.
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.
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.
> 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=...
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.
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
...
...
...
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.