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.

Makefiles are terrible tech. The problem is that they're slightly less bad than most other build system we've come up with, which makes them "useful" in a masochistic way.

Build systems tend to commit one or more of the following sins:

* Too basic: Once you try to build anything beyond a toy, it quickly becomes chaos.

* Too complicated: The upfront required knowledge, bureaucracy, synchronization and boilerplate is ridiculous. The build system itself takes an order of magnitude more data and memory than the build target.

* No standard library (or a substandard one that does things poorly or not at all): You must define everything yourself, leading to 10000 different incompatible implementations of the same build patterns. So now no one can just dive in and know what they're doing.

* Too constricting: The interface wasn't built as a simple layer upon an expert layer. So now as soon as your needs evolve, you have to migrate away.

* Too much magic: The hallmark of a poorly designed system. It doesn't have to be turtles all the way down, but it should be relatively close with few exceptions.

* Cryptic or inconsistent syntax.

I adore Make. I've written one (or more) for every single task or project I've touched in the last 20 years.

No smarts. It's just a collection of snippets with a few variables. "make run", "make test", "make lint", that kind of thing.

"make recent" = lint then run the most recently modified script.

You could do the same thing with Bash or other shells, but then you get stuck into Developer Land. Things are so much more complicated, without giving extra value. Make is just a DSL saying "files like this, are made into files like that, by running this command or two". That's it.

This is incredibly powerful!

The author is not even using the mtime-based dependency tracking. Also the targets are supposed to be PHONY but not marked as such. The author could have replaced it with a shell script that read $1 and matched on it to determine what to do.

Technically all of these make targets look for files by the names of the targets. Each one should really be defined as .PHONY.

That said, I used to write makefiles like this all the time, but have since switched to just and justfiles in recent years which make this the default behavior, and is generally simpler to use. Things like parameters are simpler.

https://github.com/casey/just

It funny that make evokes such fierce arguments, almost like the semi-religious vi-vs-emacs wars of old.

I agree fully with the OP, in particular I find it smart that he wraps anything in a top-level makefile, even if other, more sophisticated build tools are used. The advantage is standardization, not having to remember anything and to know that if you wrote it, you will just be able to type "make" and it will work.

Let's say a C person wants to compile a Rust project, they would not have to look up how cargo works, but could simply type "make" (or "gmake"; I don't use GNU specifics, but try to be POSIX compliant, even if it is certainly true that almost 100% of makes are gmakes).

Thanks for proposing the use of the timeless "make" as a sort of top-level build system driver; this will probably still work in 250 years.

Agree with the sentiment here but I've been rewriting lots of things to use Justfiles instead

https://github.com/casey/just

Avoids lots of weird makefileisims

Yes, Make is awesome. I use it for so many things. It's a great way to automate tasks. For example my personal website is built using a Makefile that calls bash scripts to rebuild the updated web pages, and I deploy it using a git push to my server and a git hook there that calls Make. However there are files that I don't want to put into the Git repository because they are blobs that may change often like PDFs of my teaching materials. It's okay, I have an "uploads" target in my Makefile that will upload only the modified PDFs to my server and this target is a dependency of the "deploy" target which does the git push so I don't even have to think about it.

Also the updated PDFs for my courses materials are automatically put into my websites source tree by another Makefile that I use to manage and build my teaching materials and which let me either build the PDFs I use from my LaTeX sources or build from the same sources alternate versions of the materials for my students (without solutions to the lab sessions exercises for example) and automatically publish those to my local website version to be uploaded whenever I want to deploy the updated website.

It's kind of Makefiles all the way down. I like Makefiles! =)

In those cases, what author really needs is just[1] not make.

[1] https://just.systems/man/en/

make as a task runner is not too bad, but there are better alternatives today like just (as others have commented).

make as a build system is ok until you hit the warts.

- make/Makefiles aren't standardized, which is why automake exists. So now you're not writing Makefiles, but templates and generating the actual makefile. This doesn't matter if you own the whole toolchain, but most people don't, so this is what some folks do to guarantee their Makefiles are portable.

- make cannot do any kind of dependency resolution, it assumes that whatever you need is right there. That leads to configure scripts, which like makefiles, are not standard, so you use autoconf/autoreconf to generate the configure script that runs before you can even run a target with make.

- make (and adjacent tools like automake/autoconf/autorefconf) use mtime to determine if inputs are out of date. You can get into situations where building anything is impossible because inputs are out of date and running autoconf/autoreconf/automake/configure leaves them permanently out of date. (fwiw, many build systems can get away with using mtime if they can do proper dependency tracking)

All in all the fundamental design flaw with make is that it's built with the unix philosophy in mind: do one thing well, which is "rebuild targets if their inputs are out of date." However this is an extremely limited tool and modern build systems have to do a lot of work on top to make it useful as more than a basic task runner.

I like Makefiles as well, and although many people have commented on the limitations and the fact that the author's usage of make is fairly simplistic, I think it's great to get started with the basics.

Kudos to the author for writing this up and _not_ feeling the need to learn every last bit of make and do everything "properly" before sharing.

I've worked on a team where GitLab CI pipelines replaced Makefiles, and I was asked not to commit a makefile to the project because it's a customized developer workflow. They were allergic to local testing, but I thought it was a great way to just store and share knowledge about how to build, test, clean, etc. Far easier to read the GitLab CI files (which yes of course were also necessary and served a different porpoise).

For me, make has two fatal flaws: 1) the lack of a builtin scripting language 2) poor recursion support

The problem with the lack of a scripting language is that I either have to do horrible shell contortions to do simple things like using a temporary file in a recipe or write a standalone script that doesn't live in the Makefile which is needless indirection. This is exacerbated by Make interpreting newlines in the recipe as a separate shell invocation, which I consider a poor design choice. It also requires needless forking for many small tasks which could be done more efficiently in process.

The lack of proper recursion means that I either have to use recursive make, which is largely considered an anti-pattern, or I have to use a flat directory structure.

What Make does have going for it is ubiquity and good performance for small projects. It is the tool most projects should probably start with and only switch to something more advanced when its scalability issues become a genuine problem.

I do this a fair amount as well. It's really just a way of documenting the configuration and idiosyncratic commands in one place, which happens to be executable. I will happily create (uncommitted) Makefiles with hardcoded paths and keys and things, since otherwise that information would go in my ~/NOTES file and there's too much in there already. My default target tends to echo out things that I told myself I needed to remember when coming back to the project.

As soon as I notice I'm reaching for anything more than `.PHONY` targets and dead-simple filename dependencies, I stop and do the real build work in something else (callable via a make target, of course!) I know how to do complicated stuff with make, which means that I know I will do it wrong. Repeatedly. Or possibly eventually do it right, but then have to maintain the resulting fire-breathing hairball.

(But to those complaining about not marking all the non-file targets `.PHONY`: lighten up. If the correctness matters so much that you're going to be messed up by a file named `all` or `build` or whatever, you've probably already gone too far down the rabbit hole and should switch to something else.)

I don't often interact with make files so when I do, I usually need to have a reference at hand. This is the best I've found yet:

https://makefiletutorial.com/

Many responses suggesting a simple bash script instead. One reason I like make is that I can just tab-autocomplete targets. No extra setup needed.

If you’re using a single entry point script (e.g. do.sh) and handling $1 you don’t get that for free.

And the moment you need to make your entry point script aware of “B requires A” then you’re going to half-bake something similar to make, anyway.

Here’s [1] my ~80 line version for Python projects (micromamba + uv) which I’ve been pretty happy with.

[1] https://github.com/giovannipcarvalho/micromamba.mk

Makefiles become a horrific technology the minute dynamic variables and the ensuing escaping games get involved. Massive footgun. Bash is already a fairly bonkers language (think from a junior engineer's perspective) and Makefiles so frequently compound that by an order of magnitude.

I like Makefiles too :) I use them more or less as a command runner, not often to build new targets based on sources (sometimes still).

In particular, I like:

* The ubiquity: it's easily available almost everywhere I touch and if not, it's usually a package install away. * The auto completion: I often define variables with default values at the top, but they can be both easily discoverable and their values can be changed just by typing `make VAR<tab>=foobar ...` * Chaining commands: make targets can be chained with `make target1 target2 target3 ...`. They will execute in the order specified. If I run this too often, I can usually create a 'ew make target that chains them all.

Make is definitely not perfect and could be simpler. My biggest griefs are:

* The abscons list of built-in variable. I can only remember a few of them ("dollar duck `$<` being my favorite), but they are not great to search in the docs and my brain is limited. * The "one line = one shell" is a bit of a PITA for the use case I have. I usually move more complicated script put of Makefiles.

I thought I would have been bitten by the M4 indentation more often, but it's not really a problem for me anymore at this point (my editor _knows_ Makefiles since it's so ubiquitous and does the right thing)

I have Just on my list of things to check, one day...

I used to hate makefiles, but really I just hated the way C/C++ make it a manual task to decide what to compile, as opposed to something like Python modules.

Now I love Make, for non-C work.

I love makefiles as well and do something similar to OP: for every repo I contribute to, especially if it's not one of mine, I'll create an uncommitted makefile to track all the shell commands that add up to my workflow within that codebase.

The ability to create dependencies between targets is the cherry on top, but the main value is just the ability to create a cheat sheet of shell snippets accessible via `make <target>` from the root of the repo.

Such a makefile is always (1) version controlled as a secret github gist (though, as personal rule, i never hardcode secrets into it), (2) committed & pushed on `make` (3) git ignored via `.git/info/exclude`. This has worked quite well for me.

One downside with this approach is that the best syntax for passing parameters down to the target from the shell is to use environment variables, which is a little awkward. `NAME=value make target` is less pleasant than `make target --name=value` would have been.

Make files: it’s a good build system in the same sense C is a good programming language. It’s also a terrible build system for the same reasons C is a terrible programming language.

I agree with everything, except that I moved to just, which runs fine on win/mac/nix and is a single-file no-dependency task runner made for this use case. It irons over a lot of warts like working directory, loads dotenv files, lets you write multiline scripts, it’s just magic.

Make has been my favourite unix tool for years and a really useful tool to have in your pocket. It’s simple, elegant, and powerful.

I do like "just" being suggested, but I strongly prefer using a very simple bash run script for tasks that do not require "make"'s extras, especially given that most modern build tools do parallelism and artifact caching internally.

Inspired by:

https://github.com/adriancooney/Taskfile

https://death.andgravity.com/run-sh

Same things can be said about shell scripts in a bin/ folder.

You could also like my tool: https://makesure.dev/

https://maximullaris.com/makesure-vs-make.html

https://maximullaris.com/makesure-vs-just.html

I also like Makefiles, but some design choices are really dated.

My latest gripe with it was its extremely poor support for filenames with spaces and special chars (;) in them: I just wanted to convert a flac library to MP3 files, it seemed well suited for the job at first glance.

I don't know what tool could be a proper replacement. scons perhaps? ninja files are too verbose. just doesn't do dependencies, job control, etc.

The correct answer is I don’t like makefiles when they are abused. They have no state yet people try use them as such and create pain for others.

I instictively know that makefiles would make a lot of things easier, but I've never found the right tutorial that would help me understand them. I'm not a 'C' programmer, and so much seems weighted to the idea that you're generating object files and linking and producing a.out.

Any good tutorials or resources for learning that show a broader applicability for makefiles?

Many have mentioned just, but I'm a much bigger fan of Earthly [0].

It allows you to write something similar to a Makefile, but everything runs in Docker. This gets you isolated builds with parallelism and caching built-in.

I've found it to be great especially for small to medium projects. For some examples, I use it to publish my personal site/blog [1] and to build a C/C++/Fortran/Rust cross-compiler targeting macOS [2].

[0]: https://earthly.dev/

[1]: https://github.com/shepherdjerred/sjer.red/blob/main/Earthfi...

[2]: https://github.com/shepherdjerred/macos-cross-compiler/blob/...

Conceptually I sometimes feel that install and clean targets should have prerequisites. The problem for clean is that make's only condition for evaluating a rule is "a prerequisite has a newer modification time" and not "the prerequisite exists". As for install, because each rule can only have a single target, the installation of each individual file would have to be a separate rule. As install destinations are usually subject to side effects (excluding nix or guix), there is usually a need to force an installation even if the prerequisites haven't been updated. And installations often require additional postprocessing that can't be captured by individual rules. So to reconsider, perhaps it makes little sense to for the install rule to have prerequisites. And forcing make to check the clean rules prerequisites might actually hamper performance, as opposed to a direct `rm`.

For me, make is definitely in the “stop worrying and learn to love it” bin. It will outlive all of us, so accept it and move on.

Am I the only one who uses make properly? I don't build C projects with it at any more (I used to use autotools for that), I use it like OP does, except I do write PHONY and I do use dependencies. I simply find the declarative way easier than writing a script. I try to avoid scripts whenever there's a better tool for the job.

I use Make fairly similarly. One fairly major footgun the author is not avoiding is their targets will break if files or folders of the same name exist.

You should always .PHONY any non-file targets though lest you want your build to break suddenly and confusingly when you add a folder named say "build" in the authors case.

Make checks file modification dates by default to see if it can eliminate steps. Setting a target as a .PHONY indicates it's a "fake target" as in a command set to be run and not a file to be written. Makes default assumption is it's being ran to "make a file" so "make foo.html" or such.

Here's a very simple example

https://github.com/donatj/force-color.org/blob/dev/Makefile

Hmm, same here. Make is my go-to toll for writing top-level instructions on how to deal with a collection of files. (re)constructing data files (including dependency tracking of course), compiling files (implicit rules are great!) and all sort of things needing to go into the toplevel directory of a project. Its easy to write, almost no syntax overhead. Compare that to ant :-) And it can get arbitrarily complex if you need it to be. Projects like buildroot are a wonderful example of how much you can actually do with Makefiles, while staying relatively readable... Sure, if you are working in big tech, your code base is likely so large now that you want ninja or some other modern build system. But for the rest of us, Make is really sufficient and actually great value for the money...

I also use make this way and have done for years. I even have the same kind of religious ritual the author has, like writing the Makefile is part of setting up the codebase and organising in my own head how the whole local dev environment is going to work.

The only thing is, this isn't what make is actually for. A number of commenters have recommended Just - the one I've been using on my personal projects is Task - https://taskfile.dev/ - which is pretty great. As other commenters have said, the problem is that make is installed everywhere already. I would love to see a task runner become standard to the same extent, and will have a look at Just if that's the one people are using.

Why use Make if they already use Gulp? Why not put that in `package.json`'s `script` stanza? And never ever use Make as a script runner without declaring the targets `.PHONY`, there will be a day when somebody has a directory (or file) named `build` or `dev` in their project root.

If you like Makefiles to run random tasks, and insist on not using the proper syntax for that, use `just` instead. It uses the same syntax, but actually for running tasks and not producing files, so you don't need .PHONY statements.

Makefiles are like exec readme.

Put complex stuff in scripts and call script from makefile.

While these npm examples are easy to grasp, they do not reflect any strength of Make. With same success one could use package.json's script property, code would be pretty much identical.

Here is Makefile "starter" I use: https://github.com/awinecki/magicfile People call this "self-documenting makefile". It migrated with me from company to company, from project to projects. Through node, php, aws, docker, server management, cert updates, file processing and many many more.

Here are some things I love about Make:

* Already installed

* Does not require some random runtime

* Does not require some random runtime version

* Same build system for (nearly) all languages

* The dependency tree can be constructed incrementally from simple, composable, verifiable building blocks

* Incremental builds are trivial

* Task bodies are (basically) shell scripts

* Isolated complexity can be moved to external shell scripts and called from a task body

* Unlike fad-language-build-systems learning is amortized across decades

* It's not CMake

Here is a quality of life one for me (if you copy pasta, remember to switch spaces to tabs). When you type `make targets`, you get a list of available targets. Kinda like `just --list`.

  .PHONY: targets
  
  targets:
     @make -qp | awk -F: '/^[a-zA-Z0-9][^$#\/\t=]*:([^=]|$$)/ {split($$1,A,/ /);for(i in A)print A[i]}' | sort

I went through a similar phase of excitement, but then realised it's a confusing layer of indirection on top of 'whatever-your-project-default-is' (e.g. npm + package.json). But I always need Make for BE+FE (small) projects, e.g. backend build with go and frontend is an SPA - this is where the power of Make to track dependencies really shines.

Back in the time we had a complex system to prepare content (encoding, metadata extraction, ...), then we tried to shive that to Make: free parallelization, partial remakes when sth went bad, for 1/100 the code and almost nothing to install. Throw a GUI to observe the filesystem and voilà. Good times.

Makefiles are ancient at this point, and work OK for what they were intended for.

The problem is when people try to expand them to everything, and they end up some arcane file full of junk nobody understands. What is a phony target anyways? And even if you understand the concept, realize it makes no sense to passerby.

Makefile enthusiasts may enjoy this audio episode on Makefile:

https://podcasters.spotify.com/pod/show/podgenai/episodes/Ma...

I too like makefiles, but the sophistication that I’ve added to some mine are a bit much and I now wish I had explained, via comments, to myself what I did :-D

That said, I wish there would come a new tool that could make things easier, that would gain wider appeal and adoption.

Not directly related, but I suggest reading the Wikipedia entry on Knife Game. It is a marvel to watch someone skilled at this.

Better article on the subject: https://rosszurowski.com/log/2022/makefiles

Take https://linuxfromscratch.org/ for a spin and see that Makefiles work fine; last a long time.

I really was surprised that the main concern in the comments here was about the missing .PHONY.

And kudos for this article that gives a point of view, then fixes the main HN concern ;-)

In my first job out of university, I inherited a data pipeline that had been written in Make using ~40 Makefiles. Needless to say, it was a hell to debug.

I kind of knew this was going to be about using make as a "task runner" instead of build system as soon as I read "ten years ago" :-)

As a guy who doesn’t write code, but reads a lot of it, Makefiles have always been a PITA to deal with. But less so than cmake or other build systems.

In short:

Person puts short shell scripts "build", "deploy" and "dev" in a single makefile as targets, instead of putting each script in a separate well named file. Then concludes that make is a great build tool as long as you don't use it as a build tool ("nothing complicated").

Please do not do this. make is not a shell. Also, consider reading (and writing) build docs, instead of running make with random targets as soon as you see a makefile

People in this thread have already listed the terrible terrible things about make. It succeeds because it's simply everywhere. And rather than attempt to improve, people romanticize the good enough solution.

I dream of a world where a "lessons learned make" is installed everywhere. How do we get that to happen?

I "hate" Makefiles, for building it's faster to use meson, zig build, cmake+ninja. For this use case, https://github.com/adriancooney/Taskfile is way more flexible and you don't need to mess with PHONY rules.

I don’t get why you’d use make just to call an NPM script in your package.json

I'm not sure that using make to run npm is the win the author thinks it is.

Make is great.

When even a simple one misbehaves, like it almost always does, I get to spend a solid chunk of time ignoring my actual goals to play with a bit of computing history.

And then I get to do it all over again a month later, when it breaks in yet another new way.

busybox make is quite restricted, which is why I write for it.

I vote to use make modestly and to release the candidate

If you like Makefiles you should try Scons: https://scons.org/

And ... there is no make test

Me too :)

Makefiles are an eerily lisplike turing tarpit. I hand wrote the makefiles for my projects, they generate wonderfully organized build trees. Hell I use makefiles to manage my dotfiles repository, even blogged about it.

https://www.matheusmoreira.com/articles/managing-dotfiles-wi...

The sanest way I've found to write makefiles is to think of it as a tool that maps input paths to output paths.

When compiling a program, I want to map source/program.c to build/$(config)/objects/program.o so I write pattern rules that do just that.

  $(directories.build.objects)/%.o: $(directories.source)/%.c | directories
          $(strip $(CC) $(CFLAGS) -o $@ -c $<)

  source_to_object = $(patsubst $(directories.source)/%.c,$(directories.build.objects)/%.o,$(1))

  directories.source := source

  directories.build.root := build
  directories.build := $(directories.build.root)/$(config)
  directories.build.objects := $(directories.build)/objects

  sources.program := $(shell find $(directories.source) -type f)
  objects.program := $(call source_to_object,$(sources.program))

  targets.program := $(directories.build)/program

  $(targets.program): $(objects.program) | directories
          $(strip $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^)

  targets.phony += program
  program: $(targets.program)

  .PHONY: $(targets.phony)

Using make without phony targets is insane. Without phony targets, I'd need to type things like "make build/aarch64/program" in order to get a build started. So I use phony targets for everything. Much easier to type "make program".

It got to the point I created a phony-targets shell script which parses make's database output and processes it into a sort of help text for any given makefile's phony targets interface:

https://github.com/matheusmoreira/.files/blob/master/~/.loca...

I've been writing [GNU] Makefiles for years, and have a love-hate relationship with the [GNU Make] tool. I tend to push tooling to the limit, I think it's in part because I believe in "soundness of scope" -- a tool should have a well defined scope and within that scope "all bases should be covered". In practice that would mean, that with Make I am able to define the dependency graph of pre-requisites and targets (files that Make makes) such that it just about handles the graph resolution complexity for me -- _with variables_, that is.

I love Make because it largely delivers on its promise -- and I am using it almost in _opposite_ to what the author describes. That is, I consider phony targets to be an "illegitimate" feature of Make, and avoid them like the plague. While convenient, targets in Make are heavily geared to be files, certainly most of the machinery in Make was written to assume so, and even the well-known (and documented) targets like "install" and "clean" leave a terrible taste in my mouth as of late, despite these being very conventional.

The problem with phony targets is that they're hard to reason with by Make (unless you actually turn "install" and "clean" into files) and break half of the rest of its assumptions on what targets should be and how they behave. The rest of the problem is the linguistical aspect of it -- if I `make install` am I making an install program/script or what? These kind of vagaries have led me firmly away from ever using phony targets.

As for the rest of it, Make is terribly archaic, but that also lends it strength since the archaic nature is very simple on the flip side.

The "hate" part is me taking a dislike to its bare-bones, in my opinion insufficient variables facility, where only truly global variables (certainly sharing one namespace) exist and juggling these for any non-trivial Makefile is always a problem of its own.

I am no novice with GNU Make, not any longer, but occasionally I need to look back into its manual to remember how e.g. the so-called double-colon rules work (when I suspect I might need one) and the real difference between the `=` and `?=` variable assignment, for when I want to provide default values and so on.

Lately I've been playing with the idea of _implementing_ a [GNU] Make compatible tool just to see if the somewhat _patchy_ scope of [GNU] Make can be given more coverage -- for instance to see if adding locally-scoped variables and more flexible target definition can improve Make? What I mean is to experiment with an implementation that retains fundamental principle and mandate of Make -- dependency graph resolution and reliance on [normally] UNiX shell -- but "upgrading" the syntax and extending the semantics. Because while Make is useful, it's also at times terribly hard to work with. To paraphrase Bjarne Stroustrup (the man behind C++), "inside Make there is a neat sound idea struggling to get out".

nobody likes makefile

I like Makefiles too.

Just not this one.

me too

me too.

[dead]

[flagged]

The author is confused about what Make is for, and frankly this kind of thing is why Make gets a bad rap. Make is for traversing a graph to determine what should be built, and how to parallelize the steps. Here he doesn't have a graph or any dependencies defined at all. He does have a weird scripting language though, which more or less nobody likes.

> Even on my MacBook, I don't remember installing it explicitly.

It's there, but last I checked, it only supports building with the Apple-supplied toolchains (Xcode). If you want to use anything else, do yourself a favor and install gmake(1) from MacPorts.

For C/C++ projects that are simple enough, I can reuse the same Makefile with only minor changes, and it works on both Linux and macOS, with support for sanitizers and valgrind(1). CLion eats it up like it were candy, although the gathering of sources is automated with find(1), and even respects my `--sysroot` setting.

CMake has good cross-platform capabilities, but GNU make gives me more control over the actual compiler and linker invocations, and its CLI is less horrible than that of CMake.

While I dislike makefiles for the same reasons many echoed in this thread, with AI it doesn't matter.

It's such an ubuiquitous gormat Llm are well trained on them.

So you don't have to read or edit it, just let the robot do it for you. It will do it well, and it's not something you do often anyway.

Then you can enjoy the other qualities of the tool, like the fact it's already there on unix, or that it's more than a task runner.

Although I prefer "just" or "doit", in 2024, make is fine again.