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.
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.
mosh is a good example: https://mosh.org/#build-instructions
"Use a recent bash" seems like a matter of preference.
"Make is all about files (paraphrasing)" seems a little obvious hopefully, but definitely the way Make is intended to be used.
"Magic variables" eh... I dunno, I guess sometimes they can get obscure but it isn't super hard to look this sort of thing up.
The omission of % seems weird.
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.
> .CPU = SECONDS
> .MEMORY = SIZE
I wish the cluster I use sometimes had this built into their make system, to prevent people from make-ing on the headnode, haha.
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.
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).
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.
https://www.gnu.org/software/make/manual/make.html
It's a peeve of mine that folks refuse to read the actual documentation for tools these days, preferring to wing it by copying other people's code.
And being forgiving of not understanding the docs requires someone to read the docs in the first place.
Most of the time I needed two or three passes in different context to start to really grasp a tool domain.
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?