I hate developers like this. This is the attitude of every weirdo developer I've had to work with who thought they were brilliant instead of just using the stupid tool as it was intended.
I don't know, I can't really argue with .SHELLFLAGS = -euo pipefail.
If you want someone to really hate, pick me. I see a Makefile and think "welp, strap in for a wild ride that isn't going to get me a working binary". If someone has ever made a good Makefile, I certainly haven't seen it.
More typically, the install instructions read like the bomb-defusal instructions in the classic MASH episode. "Cut red wire, then unscrew detonator subassembly. But first..."
> "Use a recent bash" seems like a matter of preference.
Unfortunately it's not merely a preference; old Bash versions (in particular the one that shipped on macOS for a long time) have had at least one nasty behavior (I think multiple, but I recall at least definitely one) that have been fixed since then, but which cause grief in Makefiles. I don't recall what it was or have a link handy, but if anybody knows, please leave it here; it's a well-known issue.
If you want to read something good, check out the docs for this Landlock Make project I've been working on the past week. https://github.com/jart/landlock-make It has many more features since it was announced on August 7th.
Honestly his takes (mostly) aren't wrong or niche (at least not all of them; a few like the tabs thing are debatable). Some of these you only realize once you've wrestled with Make for a while and spent time thinking about the underlying problem, which many don't do. Knowing some of these
ahead of time can save quite a bit of a headache. They're worth considering even if you don't follow all of them.
It would have been classier if they'd replaced the tab character with an emoji. That's what someone on Lobsters recommended, once I told them about .RECIPEPREFIX.
That's a strange take on the post. The post only uses built-in functionality. Options exist for a reason, and defaults are _really_ difficult to change in software used by millions of people.
What about them? I don't use Python or Golang, but I install the requested versions of each if I need to do something that uses them. Folks who don't use GNU Make can do likewise. It's not a big deal.
For me, every Mac I touch gets a GNU userland by default (and Homebrew comes with shell helpers to switch to GNU userland aliases temporarily, it isn't a hard switch unless, like me, you lock it on all the time) because it's really not worth the time and effort to remember what bits are GNU and what bits are BSD. So I picked the one that has the most stuff that makes my life easier.
There's also just the more basic thing of "the author doesn't care about portability to environments they consider out of scope," and that's totally fine, too. In 2022, the barriers to entry to installing the necessary bits of one flavor or another are very low, and if you choose to make them harder for yourself that's mostly on you.
It is of course up to the coder, what platforms they want to support.
But it isn't always easy to install new software. GNU make is so widespread that it probably doesn't matter. But for example, if you are on a shared machine where you might not necessarily have root. Or, if somebody requires some obscure build system that isn't available in your distro repos (of course you can build from source, but the need to check the source of the build system is going to increase the barrier to entry).
They usually don't matter (and unseen-untested portability is simply wishful thinking), but particularly don't matter for projects you're responsible for and decided they don't matter. That doesn't mean you must randomly preempt portability, of course.
I felt the opposite, I (among many) was winging my makefiles due to unfinished learning. I always appreciate high precision posts like these (even if some of the points are above the top).
It's high precision of a flawed view (in my opinion, of course) that should only be taken for what they are, an opinion.
For any readers that want to learn make, look at the makefiles of big projects and see how they set things up. There's a huge difference of one person's opinions vs. a working system for a real world project.
People should be a little more forgiving. Even after reading emacs Manual thoroughly 3 times, I still managed to miss a ton of nuances and information. Same goes for make or other large old tools I guess.
Well, I think my point of learning from how people actually use make in the real world to be perfectly valid for learning, as is learning any kind of language/tool.
But here's my criticisms:
> Instead, ask make to use > as the block character, by adding this at the top of your makefile:
Changing this is like replacing java curly braces with square brackets because it's easier to type. A good developer should be able to cope with different stylistic choices to match the existing code without strain IMO
Maybe if it was a greenfield project it's ok, but the article doesn't say either way.
> The key message here, of course, is to choose a specific shell. If you’d rather use ZSH, or Python or Node for that matter, set it to that.
I disagree with using ZSH as it adds another dependency and shell to learn to build your project. This introduces more ramp up in knowledge, but also something build systems will have to pull in.
The vast majority of steps end up as simple unix commands and program calling with specific flags in practice.
Python is a maybe if that's the only language you're working with. Otherwise anything but simple function calls is better served by an external file. Even a simple module function call becomes clunky on one line.
This is an interesting idea worth exploring in general, though.
> Make has a bunch of cryptic magic variables that refer to things like the targets and prerequisites of rules. I mostly think these should be avoided, because they are hard to read.
See point 1. This is like choosing to not use regex because the symbols are confusing.
~
The rest of the article has good stuff in it though, esp. the file structure and bash flags. The rest is just questionable opinion and has little impact to a good makefile.
Can you give some arguments against what I typed above?
