Comment by heads | Hacker News Reader

Comment by heads | Hacker News Reader

Make is the grilling of the hacker world. You just want to light up some quality lumpwood charcoal and get a nice smokey crust on some steaks, cook up some hamburgers, and crisp up some chicken for your guests over the course of an afternoon…

…but oh no there is a constant stream of inquisitive folk coming over, beer in hand, suggesting cool adjustments / hacks / “improvements” to your setup. With grilling it’s actually pretty easy to defend oneself from this unsolicited advice. There’s only one grill after all. It’s not like it’s some company wide grill that anyone can make changes to solely by convincing one other person to sign off on their PR / MR / changeset.

I’ve seen some very “clever” makefiles (and cmake lists.txt) over the years. It is hacker catnip for all manner of Jackson Pollock ad hoc scripting rubbish and I lament every commit that did anything except make the makefile less complex! All new software engineers should be given a shiny ball to play with when they get bored with their day job, lest they decide to take out their playful creativity on the build system instead.

make is very useful. The idea that things depend on each other and are built as a hierarchy is important.

But it is the opposite of beauty, or elegance, or organization.

Honestly all the millions of man months that have gone into writing makefiles should have gone into making make more usable.

for example:

all the implicit rules in this article? Nobody¹ uses them, they should just be explicit.

You shold explicitly distinguish between a target and a file and a directory. don't let them depend on each other helter-skelter.

indent, tabs, spaces. what a mess.

requiring continuation lines and juggling return codes?

macros that break with whitespace?

I could go on, but ugh.

I actually like cmake better than make. Just having IF statements and a flow makes things more understandable. But yeah, you trade one set of problems for another.

look up "modern cmake" and you'll see the nitty-gritty between nice theory and ugly practice.

[1] for practical purposes

Apparently the reasoning behind a bunch of Make’s warts is that by the time Stuart Feldman realized the problem, it already had half a dozen users, and, well, he wasn’t gonna go and break it for them!

I don't see why there couldn't be (even today!) some statement like "require version XYZ", which Make could notice, which would enable new features and nicer syntax. Something like "editions" in Rust, though the idea is much older.

For some reason, people prefer to add more layers on top of Make rather than improving the core language and tool. Maybe there's some good reason?

I think people treat make like a dmv trip or taxes.

They want to get in, get it done, and get out.

But who wants to improve the DMV?

> rather than improving the core language and tool

GNU Make has been steadily gaining new functions though. I've been reading the manual again recently and there were a few functions I did not recognize: let and intcmp. The new integer comparison function is particularly notable since people have gone to some rather incredible lengths to implement arithmetic in make:

https://gmsl.jgc.org

It's also possible to write native plugins for GNU Make to load at runtime. New functions can be implemented this way. It works just like C extensions for other scripting languages. There's also Guile extension support but unfortunately it doesn't seem to allow new function definitions.

> arithmetic in make

Well that’s horrifying. What is the use case? Or is it just hackers gonna hack?

Incrementing a counter would be one example. Like maybe you want to produce file-00.txt through file-99.txt.

idk about anyone else but I have auto incrementing build numbers in several makefiles

That would seem to be the most obvious and trivial example and I just assume that there must be countless others without having to actually see them and agree that they are valid.

Wait, how could I forget the other most obvious example, comparing version numbers of requirements/dependencies?

The Vala preprocessor can't compare numbers and so I have to implement "if libfoo < x then add -D OLDFOO" outside in the makefile and can only have boolean #if OLDFOO in the code. (libs don't always provide good enough equivalents, maybe only provides a numerical value that you are assumed to be able to compare, or maybe provides nothing at all, or does provide a set of booleans intended to be used for this but they aren't granular enough, etc)

All I can say about these critiques: I learned make a few years ago and it wasn't nearly as bad as it was made out to be.

As someone who cares about the aesthetics of code, I thought I would hate using make but I ended up enjoying writing modern makefiles.

When make was created back in the day, I get why certain choices were made, like with virtually all Unix tools of that era. But we don't have to use them in the same way. In general, our tooling is so much better that the so-called warts of make are more like minor annoyances than show stoppers.

The beauties of make are:

* It actually does the complicated job correctly, or can, it provides the means to. A lot of things that claim to be "new better make" are simpler by being simply incomplete and/or internally more magic and less correct and less deterministic.

* Single simple binary. No freaking python or ruby of just a certain vintage and 500 modules but maybe not the system ones or maybe only the system ones...

* Always available everywhere, not just in the middle of the bell curve of modern and popular systems, and will be tomorrow exactly the same as yesterday. Deviations like gmake vs bsdmake are essentially trivial and don't really break anything or present any real problem. IE: portable across both space and time in all directions of all dimensions.

Make is sane for the job it does. It's a great example of a correct use and application of a DSL.

And all those complaints are still true. I address them by:

* Simply adopt a habit or discipline to voluntarily avoid the implicit features. Don't use globbing either. Just don't use those features that are unwise. They are still there, but you don't have to invoke them.

* Just suck it up and deal with the tabs and whitespace and line-continuation and quirks like how each line of shell in a target is a new shell environment unless you build the annoying long single command, capturing exit values so they don't reach the parent make process and get treated as an error, etc. Whatever. To me that's all just normal shell scripting requirements in any context, make not especially different from cron or cgi or other. Rather that than passing around powershell objects or something.

Could be better but ninja or whatever is not the answer to those minor annoyances.

Agree on implicit behavior.

Actually I think it's fine for the implicit automatic features to exist, I just think no one should use them in most cases.

It's fine for a tool to try to be as magic as possible, as an optional thing you can do whaen you decide you want. And for practically any makefile that you are bothering to actually write into a file that you are keeping and running again tomorrow, and giving to someone else to run some other day on some other machine... everything should be explicit. Just like the projects code, it's documentation as much as function, and no part of either the documentation or the function should be left unexplained and undetermined.

But that's a seperate issue from the tool having the ability. I think it's not a tools job to tell me what I want and why and what is and is not valid. If make never had the magic features, I would not miss them feel any need to invest in adding them, but if they are there anyway somehow, I also don't see any reason to remove them or create a new tool just to have something that doesn't have them.

I should be free to write a short super convenient fully magic 3-line makefile that just says "do the likely thing with whatever is in this directory", and at the same time, no project should ever have that as their real makefile. Both stances are valid at the same time, I think.

Reply on news.ycombinator.com