jart
4 hours ago
Don't be discouraged by all the people in this thread saying you're using make wrong. One of the things that makes make a great tool is how deceptively simple it is. Yes not using .PHONY can potentially get you in trouble. But for a small project that's the sort of trap you'll fall into a year later, if at all, and even then you'll only be scratching your head for an hour. 99% of the time you don't have to care about doing things the proper way. Make lets you just hit the ground running and only imposes as much complexity as you need to keep the thing from falling apart.
ReleaseCandidat
an hour ago
> One of the things that makes make a great tool is how deceptively simple it is.
One of the worst things of Make is how deceptively simple it looks.
Make does exactly one thing: it takes input files, some dependencies and generates _exactly_one_ output file. To have rules which don't generate output (like `install` or `all` or `clean` or all targets in the article) we need to resort to a hack, a special magic target like `.PHONY` (which hasn't been part of POSIX up to the 2017 version - IEEE Std 1003.1-2017 - https://pubs.opengroup.org/onlinepubs/9699919799/utilities/m..., only the current one - IEEE Std 1003.1-2024 - https://pubs.opengroup.org/onlinepubs/9799919799/utilities/m... includes `.PHONY`). If you want to generate more than one file (like an object file and a module or a precompiled header or ...) you are on your own to build some brittle hack to get that working. Don't forget that not every Make is GNU Make, BSD and other nix like Solaris/Illumos still exist.
Don't get me wrong: Make has it's uses for sufficiently complex projects which aren't too complex yet to need some "better" build system. Problem is that such projects may get too complex when more code is added and they inevitably gain some sort of scripts/programs to generate Makefiles or parts of Makefiles (so, an ad hoc meta build system is created).
And the problem isn't that they use it, but that they are proposing it as a solution to "everybody". And that their Makefile stops working as soon as there is a directory (or file) `build` (or `dev` or ...) in the project root.
chipdart
2 minutes ago
> Make does exactly one thing: it takes input files, some dependencies and generates _exactly_one_ output file.
Not true. Your dependency graph might culminate on a single final target, but nothing prevents you from adding as many targets that generate as many output files as you feel like adding and set them as dependencies of your final target.
Think about it for a second. If Make was only able to output a single file, how in the world do you think it's used extensively to compile all source files of a project, generate multiple libraries, link all libraries, generate executables, and even output installers and push them to a remote repository?
> To have rules which don't generate output (like `install` or `all` or `clean` or all targets in the article) we need to resort to a hack, a special magic target like `.PHONY`
I don't understand what point you thought you were making. So a feature tha boils down to syntactic sugar was added many years ago. So what? As you showed some gross misconceptions on what the tool does and how to use it, this point seems terribly odd.
jart
an hour ago
I work on a project with 4.4 million lines of code and using a single Makefile with no generated code works fine. It's really not all that difficult.
wruza
41 minutes ago
Projects of much smaller sizes often have recursive convoluted makefiles.
ReleaseCandidat
39 minutes ago
And I can show you thousands of "Hello World"s that use GNU Autotools or CMake ;)
But seriously: can I take a look at it (Soource + Makefile)?
oblio
an hour ago
> 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).
miki123211
6 minutes ago
> 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.
elktown
6 minutes ago
> 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.
ReleaseCandidat
43 minutes ago
> He's not using C, though :-)
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).
chipdart
10 minutes ago
> Don't be discouraged by all the people in this thread saying you're using make wrong.
Fully agree, and I would add that it's far better to adopt the right tool for the job, even if you are not an expert, than avoiding the criticisms from perfectionists by adopting the wrong tool for the job.
Everyone needs to start from somewhere, and once the ball is rolling then incremental changes are easy to add.
Great job!