> If you want to generate more than one file (like an object file and a module or a precompiled header or ...)
He's not using C, though :-)
> And the problem isn't that they use it, but that they are proposing it as a solution to "everybody".
He's proposing it for the same reason I'm starting to like it, after many years in the industry: as a simple build wrapper.
> And that their Makefile stops working as soon as there is a directory (or file) `build` (or `dev` or ...) in the project root.
And they can fix that problem in 5 minutes, big deal :-)
> Don't forget that not every Make is GNU Make, BSD and other nix like Solaris/Illumos still exist.
This is a very bad reason in this day and age. 99.999999% of *NIX usage these days, probably 99.9999999999999999% for the average person, since most people won't ever get to those environments where BSD and Solaris are still used, is Linux.
And even for BSD and Solaris, guess what... you add an extra step in the build instructions asking them to... install GNU Make.
Heck, even back in 2005 (I think?) for Solaris one of the first things you'd do was to install the GNU userland wherever allowed because the Solaris one was so forlorn I swear I heard wooden planks creak and dust pouring down every time I had to use their version of ps.
And regarding POSIX, meh. If you're a C developer (C++, Rust, I guess), knock yourself out. Most of the stuff devs use are so far removed from POSIX... Actually, not removed, but has so many non-POSIX layers on top (I mean not standardized). Ruby bundler is not standardized like awk. Python pip is not standardized like make. Etc, etc. That's the reality we're in. POSIX is very useful but only as a very low level base most people don't need to chain themselves directly to. I'd definitely not avoid a tool because it's not in the latest POSIX standard (or only in the latest POSIX standard).
As said elsewhere, the use-case in the article is too simple to warrant a Makefile. So: if you aren't compiling some static language, you do not need - and certainly don't want to use - Make.
> you add an extra step in the build instructions asking them to... install GNU Make.
The main reason to use Make is that it is installed everywhere, as stated multiple times in other posts. If you must install something, you can also install a better alternative for your specific use-case to Make.
> one of the first things you'd do was to install the GNU userland
Yes, and the Unix vendors even shipped them on companion CDs or similar.
> is not standardized like awk
Same problem with awk (and sed and ...): some weeks ago I had problem with the SDK for some real-time Linux that works with mawk only, and not with GNU awk (most of the time it's the other way round, only working for some GNU program).
> As said elsewhere, the use-case in the article is too simple to warrant a Makefile. So: if you aren't compiling some static language, you do not need - and certainly don't want to use - Make.
I've found that I prefer make as a command runner and most of the time I'm just running Python poetry commands or building Docker containers or running AWS infra commands. It's very useful to have a simple tool to run commands and have them depend on each other.
And regarding many of the alternatives to Make, they're either more complex or have other issues:
That depends if the person who must do the porting knows Make or not and which GNU Make (it's always about GNU Make!) feature had been used. And chances are JS devs don't at all or just as little as the one who wrote the article.
Don't get me wrong: I don't like Make, but I hate CMake and Autotools (and many other C++ build systems) too (and C and C++ and Fortran compilers and their vendors).
> And they can fix that problem in 5 minutes, big deal :-)
Honestly, a big issue I see is that people can somehow argue with a straight face (and successfully too!) to invest weeks of work introducing a pet project to avoid a 1 hour inconvenience that happens once every blue moon. Proportionality takes a backseat very quickly to motivated reasoning.
It's a general observation on over-engineering, "resume driven design", and proportionality being somewhat of a blind spot in software. But yeah, I'm not going to lie, my brain certainly patterned matched towards "this is going to be a Bazel guy isn't it?". So, Buck2 was close enough. Those are exactly the kind of multi-week pet projects I'm talking about that are too often introduced under vague and disproportional pretenses. Well, multi-month and dedicated specialists going forward are perhaps more accurate for those. But maybe that's the point.
But my argument has been that _Make_ is already too complex for the given task.
And talking about complex C and C++ (to be fair, the complex ones are almost always C++ ;) projects, I would not say that CMake (or Meson or ...) is less complex than Buck 2, it certainly has _way_ more magic than Buck 2. And getting Make & C++ & ccache(or whatever) & distcc (or whatever) to work _reliably_ isn't easy either ;)
> This is a very bad reason in this day and age. 99.999999% of *NIX usage these days, probably 99.9999999999999999% for the average person, since most people won't ever get to those environments where BSD and Solaris are still used, is Linux.
You have a lot of confidence. In reality, it's probably more like 30-60%, more now because of WSL. The rest is Mac OS, which uses a BSD userland and hence BSD make by default.
Why would they do this? I could understand using a non-GPL make because they hate it, but using an ancient GNU make is just handicapping your users for no gain.
Apple has restrictions about what software on the system you can modify as a user and how, in the name of security. GPL 3 is unfriendly to such restrictions. Whether what Apple is doing on the Mac specifically violates GPL is, well, a matter of debate that has never been tested in court, but Apple thinks there's at least some risk there, and that the risk isn't worth taking.
This is also why ZSH is now the default shell on the Mac. ZSH never switched to GPL V3, so it was either that, remaining on some god-awful old Bash version, or making their own.
Don't ask me. One could argue that this is the version they included in some early version and have kept for compatibility reasons, but that doesn't make(sic!) sense.
He's not using C, though :-)
> And the problem isn't that they use it, but that they are proposing it as a solution to "everybody".
He's proposing it for the same reason I'm starting to like it, after many years in the industry: as a simple build wrapper.
> And that their Makefile stops working as soon as there is a directory (or file) `build` (or `dev` or ...) in the project root.
And they can fix that problem in 5 minutes, big deal :-)
> Don't forget that not every Make is GNU Make, BSD and other nix like Solaris/Illumos still exist.
This is a very bad reason in this day and age. 99.999999% of *NIX usage these days, probably 99.9999999999999999% for the average person, since most people won't ever get to those environments where BSD and Solaris are still used, is Linux.
And even for BSD and Solaris, guess what... you add an extra step in the build instructions asking them to... install GNU Make.
Heck, even back in 2005 (I think?) for Solaris one of the first things you'd do was to install the GNU userland wherever allowed because the Solaris one was so forlorn I swear I heard wooden planks creak and dust pouring down every time I had to use their version of ps.
And regarding POSIX, meh. If you're a C developer (C++, Rust, I guess), knock yourself out. Most of the stuff devs use are so far removed from POSIX... Actually, not removed, but has so many non-POSIX layers on top (I mean not standardized). Ruby bundler is not standardized like awk. Python pip is not standardized like make. Etc, etc. That's the reality we're in. POSIX is very useful but only as a very low level base most people don't need to chain themselves directly to. I'd definitely not avoid a tool because it's not in the latest POSIX standard (or only in the latest POSIX standard).