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.
> 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.
> 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 old I swear I heard 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.
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.
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.
"The author could have replaced it with a shell script that read $1 and matched on it to determine what to do."
Or just with a simple command runner like just.
The strengths of make, in this context where it's been coaxed into serving as a task runner for small projects, are:
1) It's already installed practically everywhere
2) It reduces your cognitive load for all sorts of tasks down to just remembering one verb which you can reuse across multiple projects, even if the implementation ends up differing a bit
3) In conjunction with the similarly ubiquitous SSH and git, you have everything you need to apply the basic principles of DevOps automation and IaC
There's something special about waking up one day with an idea, and being able to create a fresh git repository where the first commit is the Makefile you've had in your back pocket for years that scripts everything from environment setup to deployment to test automation to code reviews.
There's zero effort beyond just copying your single file "cookbook" into that new repo.
> It's already installed practically everywhere
Well, except Windows. But nobody uses that right?
> It's already installed practically everywhere
This always comes up, and is a sad chicken/egg problem.
We can all somehow agree that Make mostly sucks, but OS maintainers aren’t interested in providing a default alternative, due to choice overload or something.
Or just with a simple command which is guaranteed to be on most Linux systems already - make.
Maybe his Makefiles aren't complex, nor they seem to follow all the best practices invented by code gurus in sandals, but it works and, what's important, it works for him.
There was a time when people would have said the same about make. The shell is the simple command that is guaranteed to be on all Unix systems from the get go. Make is the new kid on the block.
If you just want to run commands in the order written down, don't need the topological sorting feature of make and value ubiquity then a shell script is the answer.
If you are not stuck in the past and you truly live by the UNIX philosophy of doing one thing and doing it well, a command runner is the answer.
The command runner avoids the ton of foot guns both shell scripts (no matter which flavor) and make files have. just also brings a couple of features out of the box that would be very tedious and error prone that replicate in make and shell scripts.
Right but writing dependency management (of targets, not package management) in shell seems like a nightmare compared to just leveraging make. Why complicate things? It's dead simple to debug, the interface is dead simple, what's the downside?
Right, but the original point which started the thread is that "The author is not even using the mtime-based dependency tracking", in which case a plain shell script is very much a viable alternative to make.
I don't particularly mind this use of make, but as an article on make it fails to exemplify what I think is its main purpose.
In my PS script solution, I just added a clean option+command.
I rewrote my makefile in PS and don't miss anything from make and have no regrets, as it is simpler now.
>Make is the new kid on the block.
Make is from 1976. I don't think you can legitimately refer to it as that.
The first UNIX was announced outside of Bell Labs in 1973. In 1976, pretty much every tool was “the new kid on the block”.
You could around 1976. Who's ever going to need make.
I believe you to be correct. I think it's important that one uses the right tool for the job, regardless of whether or not it's widely adopted or supported.
> but it works
That it what a lot of SW developers forget: your code might be the best in the world, but , if someone is not able to build it, it is useless.
> it works and, what's important, it works for him.
Until it doesn't. And then you really have to learn about PHONY targets, why and when there must be a tab and not spaces - good luck with an editor that doesn't treat Makefiles special and is configured to convert tabs to spaces.
But those are things that he’ll learn about as he keeps using make. And why does it matter that some editors don’t know about makefiles? The one he is using handles them just fine so what’s the problem?
> And why does it matter that some editors don’t know about makefiles?
Because it isn't fun checking if the whitespace at the beginning of the line is a tab or spaces. And as said, you must know when to use tabs and/or spaces in rules.
For doing such a simple thing as calling some commands, Make has way too many subtle footguns which _will_ bite somebody, someday. The problem (that's not a problém at all, that's a reason to celebrate!) is that most JS devs and users aren't used to Make, compared to e.g. C programmers. To rephrase: as someone writing C, you have to use something like a Makefile, as anything else (like scripts) gets unreadable and -usable quite fast. But if you can get away with a less complex solution, you should really use that instead of Make.
> Because it isn't fun checking if the whitespace at the beginning of the line is a tab or spaces. And as said, you must know when to use tabs and/or spaces in rules.
that's why https://editorconfig.org/ exists, so that neither you nor your teammates have to think about these things
> neither you nor your teammates have to think about these things
You're better off using a Makefile linter. But you must know about the problem before being able to solve it. And error messages like
Makefile:2: *** missing separator. Stop.
Please help me understand why this thing exists. Like, no snark, I like using the proper tool for a job -- when would I look at the project and think "this is something that is better done with 'just' tool". Instead of readme.txt and a folder with scripts
I can count on one hand the number of times a simple script or make worked out of the box. Sure, part of the reason is dependencies, but then I might as well use a build tool that is actually doing what a build tool should. Makefiles/bash scripts are hacks, and I don’t get this strange Stockholm syndrome UNIX-people have for them.
Why not just use make? I am constantly confused by people reinventing the wheel with new syntax and little benefit
why do you need a "command runner"? Have you heard of bash functions? Or... make? The thing is too simple to justify installing another tool, however nifty it is.
Here’s a one-line horror story for you (from a real project I’m working on):
.PHONY: $(MAKECMDGOALS)
Sure, but `./build.sh dev` is a bit less obvious than `make dev`.
Another reason to use Make even if you don’t have any non-phony steps is that you can add those later if needed. (I agree that the author should mark {dev,build,deploy} as phony though.)
Why is this a horror story? Under certain assumptions of how the author intends to use this, this sounds like a sensible way to define a dynamic list of phony targets to me, without having to specify them by hand.
There are many reasonable scenarios why you might want to do this: determining at the point of calling make which targets to force or deactivate for safety, projects with nested or external makefiles not directly under your control, reuse of MAKECMDGOALS throughout the makefile (including propagation to submakefiles), ...
Consider:
.PHONY: $(MAKECMDGOALS)
qux:
foo: qux
bar: foo
It also very much depends on what the intent is, notably such a "autophony" make foo is very different from make -B foo.
I got an even better one for you: `./dev.sh`. The author is doing it wrong, and giving Make a bad name.
First of all, misusing a tool doesn’t “give it a bad name”, and second of all who cares? A tool isn’t a human being. Make’s feelings aren’t going to be hurt by this article.
The author just shared something they think is cool. That takes guts to show the world, and our critiques should respect that.
You’ll also want ./build.sh and ./deploy.sh then. If each is 1-2 commands, I’d argue it’s a waste to use separate files here.
> giving Make a bad name
How so?
> I’d argue it’s a waste to use separate files here
Fine. Write a `make.sh` that parses the arguments; that would be better.
> How so?
Well, read the comments here. Do you sense that Make is a beloved tool? Most of the complaints are about some details about syntax, and those complaints are completely valid. If you use Make for its intended purpose, then it's still easily well-worth using, despite that. But if you use it as a glorified script, then all you see is the warts, without any upsides. And you then tell all your friends that "Make sux!" Which is a huge shame because Make is awesome.
Hear hear!
That's fine, the separate files are a benefit here. The only annoyance is clogging up the root project folder -- though some people don't seem to care about that. If they got too numerous (the 5 in OP's "more advanced" project would probably not be too numerous), I'd consider putting the scripts in their own folder. I might even call it 'make' just to mess with people. Then my commands are just make/build and make/deploy and so on (.sh unnecessary). But really, in OP's case, I just have no need for some of their simple wrappers. "npm run dev" is two characters longer than "make dev", pointless.
We all were beginners at one time or another. And if you want to learn a tool, it helps to actually use it, even if your greenhorn usage is less than perfect. You can make incremental improvements as you learn, like we all do.
While you're technically correct, what I gathered from their experience is the consistency of usage, between not only their own projects but third-party projects too.
They could make technical improvements to their own Makefiles, sure. But it's more about being able to enter a project and have a consistent experience in "getting started".
> But it's more about being able to enter a project and have a consistent experience in "getting started".
I'd say putting the Makefile content in `package.json` would be more consistent, especially as they are already using Gulp as the build system.
You can't put comments in package.json, JSON should never have been used for something maintained by humans.
We are not arguing whether not declaring phony targets is worse than using comments in `package.json`?
But anyway, comments in a Makefile or `package.json` are not documentation anyway, that's what the `README` or `INSTALL` (or whatever) is there for (in projects like the one the Makefile is written for).
That's the beauty of make and shell, it's follows the UNIX principle of being simple and doing one thing and one thing well. People want it to do many other things, like be a scripting language, a dependency tracker, etc, so they're willing to pull in bloatware. New isn't necessarily better. Autoconf and automake isn't make.
None of them are simple, they are chock full of hacks upon hacks, “fixing” their own idiocies, and by extension, none of them are doing their one thing well. Especially bash scripts, they should be left behind..
Is this satire? Being a scripting language and tracking dependencies are primary features of shells and Make, respectively.
Not satire, sorry I didn't clarify. They want make to have a builtin scripting language rather than using shell scripts, and a dependency tracking system that more complex and less tooling agnostic rather than leveraging the appropriate tool (like `npm ci`).
The author also seems not to have discovered 'make configure' and the horrors of the automake/autoconf toolset and the m4 macro language.
Sure but these are completely orthogonal to make. Might as well complain about gcc.
If anything, it's an argument for making better use of make's own features for configuration in the first place.
what are those horrors about?
Have you tried writing (or even just reading) a configure.ac script?
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.
My 2c: Makefiles are excellent tech, just that a lot of people haven't learned to use it properly and use it as it was intended. I'm sure I'll get pushback, that's ok.
- Too basic: At least half of the software I use just uses plain makefiles and maybe a configure script. No autotools. I optionally run ./configure, and then make and make install, and it just works. I definitely wouldn't consider my setup to be a toy by any stretch of the imagination. It's built out of smaller programs that do one thing and one thing well.
- Too complicated: I don't know, I think make and how it works is really easy to understand to me at least. I guess everyone's had different experiences. Not necessarily your case, but I think usually it's because they had bad experiences that they probably blamed make for, when they were trying to build some complex project that either had a bad build setup itself (not make's fault), or without the requisite knowledge.
- No standard library: It's supposed to be tooling agnostic, which is what makes it universally applicable for a very wide range of tools, languages, and use cases. It's viewed as a feature, not a bug.
- Too constricting: I'm not sure what you mean here, it's designed to do one thing and one thing well. The simple layer is the dependency tracking.
- Too much magic: Cryptic or inconsistent syntax: See 'Too complicated'
> Once you try to build anything beyond a toy, it quickly becomes chaos.
Of course the chaos is not caused by, "very hypotheticaly" let's say, a compiler or maybe a language without modules.
How would you estimate that ? 20%, 40%, or 70%, true ?
There are projects that generate files, depend on multiple languages, etc. If you push the job of a build tool to the compiler infrastructure, then why even have a “build tool” in the first place? Make is simply anemic for anything remotely complex, and there are countless better tools that actually solve the problem.
Good luck writing Makefiles for Fortran, OCaml or (whenever they will really, actually work) C++ modules.
There aren't many widely used build systems that can handle such dynamic dependencies without some special "magic" for these, the only one that I know of (with a significant number of users, so not Shake) is Buck 2 (Bazel and all C++ build systems use "special magic", you can't write in user rules).
Not OP, but its not just that C/C++ lacks modules. I think that is missing the real issue. Any complicated program probably needs a custom developed tool to build it. As a simple example, imagine a program that uses a database - you want to keep the sources as SQL and generate classes from them. Thats a custom build step.
Its just that in some languages and build systems (Node, Maven), we have abstracted this away by calling them plugins and they probably come from the same group that made the library you need.
No such pluginsystem exists, as far as I am aware, for makefiles.
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!
> Make is just a DSL saying "files like this, are made into files like that, by running this command or two".
Nicely put.
Decades ago i wrote a testing framework in java where you could specify your tests and their dependent classes using make-like syntax. So you could have a set of test classes which define the "baseline suite", then another layer of test classes which is dependent on the above and only run if the above is successful and so on.
I really do not understand why folks today make everything so complicated. My advise has always been, stick to standard Unix tools and their way of doing things (tested and proven over time) unless you run into something which could absolutely not be done that way. Time is finite/limited and i prefer to spend it on System/Program Design/Modeling/Structure/Patterns etc. which are what is central to problem-solving; everything else is ancillary.
Somehow every make file I’ve encountered in the wild is a lot more than “that’s it”
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.
I kinda like these make-ish systems, but they all have one problem: Make is already on any Linux and Mac, and is pretty easy to get on Windows as well. (It’s a real pity they don’t include it in the Git Bash!) Just using the lowest common denominator is a big argument for Make IMO.
You have to handle dependencies either way to build a project - what’s one more tiny executable?
This criticism might make sense for some non-vim editor because you might have to ssh into a remote location where you can’t install stuff. But if you should be able to build a project and thus install its required dependencies, then you might as well add one additional word to the install command.
yeah just is really cool but it's not really commonly installed so that's kind of annoying.
i feel like we're due for some kind of newfangled coreutils distribution that packages up all the most common and useful newfangled utilities (just, ripgrep, and friends) and gets them everywhere you'd want them.
But I want please, ag and friends! The "problem" with this kind of package is that everybody wants something else. And the chances that they get a part of the default MacOS or Windows install (or even part of the XCode command line tools or Plattform SDK (or whatever that is called now)) is quite small.
I like `asdf` a lot for this, but I actually don't use it for either of those examples (though it does have plugins for them). Ripgrep is in most package repos by now and all my dev machines have a Rust toolchain installed so I can build and install `just` from source with a quick command.
I think parent meant to have it pre installed in most distros, not just easily installable
Sure, really though I don't understand why installing a single binary which is available from several easy to use package managers somehow becomes an insurmountable barrier for people when `just` is involved. "If it's not already on my system I can't use it" seems like an absurd limitation to place on your projects.
Please talk to security. My machine is locked down so tight I need a director (or higher) override to get anything not in the default distribution or "blessed" by security installed, and I can't even be the one to install it. May you never have to work at The Enterprise. It sucks!
At that point wouldn't you "just" download the source and compile locally? Since you presumably could compile stuff. Add a 'bin' folder in your home directory to your PATH and enjoy.
So how do you build any project, which have countless dependencies that all have to be installed?
That sucks for sure, I did work a giant enterprise for a few years and it was plenty painful but not that bad at least. Well maybe it was that bad, because we didn't use make either, everything had to go through Jenkins and nobody bothered with anything for local development beyond an occasional `build.sh` somewhere in the project. Simply push your code when you think it's done and wait 30 minutes to get the next set of linter errors.
oh i have no problem at all installing stuff in my own environments, i'm all about having cool new tooling -- it just starts to get a little rude to ask others to do so in order to use something you're distributing (and therefore absent coreutils-ii-electric-boogaloo installed everywhere, i'm much more likely to reach for make, unfortunately).
Maybe it's different kinds of projects then. For most of what I work with distribution would have nothing to do with the build system in the repo, only people who would ever have to deal with it are other contributors that likely have some environment setup to do regardless.
Meanwhile gradle people are like: just run these included gradlew or gradlew.bat files, they'll download the actual gradle from somewhere online, pollute some folders in your home dir, and then execute the build stuff.
I notice just has some pre-built binaries that could be used for the same thing. I find it a little beyond rude what gradle normalized, but hey, it "works", and it removes the source of friction that's present any time you violate the principle of least surprise with your choice of build tool.
The reason why Gradle needs this junk in the first place is that they aggressively change and deprecate APIs. Tried to build a 6 year old project today and of course nothing works. Gradle wrapper proved pretty useful here. Make, on the other hand, has maintained almost perfect compatibility since it's inception.
I have more than once considered writing a Makefile shim that would check for just, install if needed and proxy all commands to it...
Do it!
Like moreutils? yamu? Yet another moreutils?
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).
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.
> make cannot do any kind of dependency resolution
dependency:
...
target: dependency
...Tracking build targets is not dependency management except with handwaving
> make cannot do any kind of dependency resolution
Ignorant's question: isn't dependency resolution the core of make? What are you referring to here?
> 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
The ancient convention there is "make configure", which sets up whatever "make [build]" needs.
the only thing I really miss in make is the ability to resolve mtime as something other than mtime. So I resort to using touchfiles which are gross but still work better than a lot of other things (I'm looking at you, docker build caching).
Agree with the sentiment here but I've been rewriting lots of things to use Justfiles instead
Avoids lots of weird makefileisims
It's true, although GPT has given Makefiles a second life by helping write them, delaying their demise.
Same. Bonus that the same file works on Windows too
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:
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.
You can use .ONESHELL: to switch to the shell behavior you are wanting.
https://www.gnu.org/software/make/manual/html_node/One-Shell...
That's for GNU make, not POSIX make [1]. For some people, they either won't, or can't, use GNU make.
[1] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/m...
Who even implements an alternative implementation to GNU make? FWIW, no one "can't" use GNU make... even Apple uses GNU make (hell: they even ship GNU make, lol).
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.
Thing is, make is not readily available on windows. It should’ve been in git bash, in my opinion, but just fills the gap in a cross-platform way
In those cases, what author really needs is just[1] not make.
just is just another dependency. make is available everywhere
Make is available in a lot of places, but not everywhere. It has to explicitly be installed in containers and in some distributions.
I rather have one justfile than have one make and another nmake to support Windows
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.)
> If the correctness matters so much that you're going to be messed up by a file named `all` or `build`...
That's not the problém. _We_ know what "dev is already up to dáte" means, but chances are people who don't know about `.PHONY` don't.
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.
Stop spamming the thread with petty tool people don't actually need.
Just really is great, you should just give just a try. I put all the project-specific incantations in my Justfile and save my teammates lots of typing and copy-pasta.
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:
I would theoretically prefer that as well, but it doesn't give you shell completion of targets/tasks for free like Make does. So for "UX parity", you'd also have to write a completion script and get users to source it into their shells somehow, which isn't great.
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 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?
Some simple examples : https://stackoverflow.com/questions/101986/what-are-the-othe... and https://ivan.sh/make/
A good detailed example; Using GNU Make to Manage the Workflow of Data Analysis Projects (pdf) here : https://www.jstatsoft.org/article/download/v094c01/1368
More generally, also take a look at how to use Unix Tools effectively, see; Unix : Concepts and Applications by Sumitabha Das and The Unix Programming Environment by Kernighan & Pike.
There is much misunderstanding about Makefiles, what they are, and what they are not. Make is not a "programming language build system" as some would imply, but rather a recipe builder. With Make you provide the file you want built, the shell commands to build it, and any files the build depends on.
Here's a simple example to get you started. Create a file named "Makefile" with the following text and an empty file alongside it named foo.txt.
bar.txt: foo.txt
cp foo.txt bar.txt
When people use Make to compile their C code they are simply invoking the C compiler just like they would any other shell command. You might have seen something in a Makefile that looks like this:
foobar.o: foobar.c
gcc -c foobar.c
I hope this helped!
> When you run the "make" command in your shell it will check if the "bar.txt" file exists.
I got to this point and ran into an error: Makefile:2: *** missing separator. Stop.
Ok I'm just giving you a hard time, and you mention right after the existence of "tab indented" so whatever. Still it's one of the things I detest on an aesthetic level about make, even if my editor has special syntax support for makefiles to handle this archaic requirement of actual tabs without me ever having to worry about it in practice.
I have a suspicion that a lot of people who rant about makefiles using tabs also praise python for the brilliance of using whitespace for scoping. Or who love yaml for its indented block structure.
Nah, who am I kidding ... no one loves yaml, it's just better than most of the alternatives.
I quite like python's whitespace requirements, but notably it doesn't care what your stance is on tabs vs spaces, or how many spaces, so long as you're consistent in a block. Never liked yaml, though, I don't think it's better than any of the alternatives.
> Still it's one of the things I detest on an aesthetic level about make
There's a little-known variable called .RECIPEPREFIX that lets you switch from tabs to anything else. Probably a bad idea to use it in anything shared with anyone else.
That's for GNU make, not POSIX make [1]. For some people, they either won't, or can't, use GNU make.
[1] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/m...
unironically, the info manual. It's great.
the philosophical "c" centredness is true, but doesn't get in the way of using other languages. (there's things like indirect rules for compiling .c files auromatically for instance, but even this can be turned off)
> and so much seems weighted to the idea that you're generating object files and linking and producing a.out.
Well that's kind of wrong (it's used for that but that's an extremely limited viewpoint). Here's a short introduction to get started:
foo: bar
baz
Here's an example in a totally different context:
.PHONY: build
build: node_modules
node_modules: package.json yarn.lock
yarn install
touch node_modules
This example isn't terribly useful because "yarn install" is fast and doesn't do anything itself when it's up-to-date, but it should give ideas about how flexible make actually is.
One of the big criticisms of how people use "make", and why people recommend things like "just" instead, is they don't bother to use that functionality (or any of the piles of stuff built on top of it like pattern matching) and would have just done:
build:
yarn install
Same things can be said about shell scripts in a bin/ folder.
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.
Because my Rust, Python, bash, Perl, etc. projects aren't impressed with the `package.json` file I wave at them. Especially before I've installed npm or any other JS runtime on my system (let alone Gulp).
As the article said, it's generally installed everywhere as soon as you install any dev-related stuff. So is bash, but it's a little clunkier for very basic usage. (`if [[ $1 = build ]]; then...`)
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.
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.
Take out the dashes and that's a supported syntax for overriding variables:
NAME := foo
test:
echo "name is $(NAME)"
$ make test
echo name is foo
name is foo
$ make test NAME=bar
echo name is bar
name is barThe 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 "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 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.
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.
Makefiles are like exec readme.
Put complex stuff in scripts and call script from makefile.
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.
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" :-)
Better article on the subject: https://rosszurowski.com/log/2022/makefiles
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...
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
Personally, I've always created shell scripts too. Or PowerShell scripts if I need Windows based support (like for Golang projects that might see Windows based usage.) I find they're way, way better and easier to work with.
That being said, the only issue preventing me from using shell scripts well is shared code. Like common functions etc. So far I've simply used a common.sh script and sourced/imported it.
Also, what do you do once you have 4-5 shell scripts at the root of your project? I find it gets messy quickly. I need a solution for this.
But yes, I agree shell scripts are generally better.
> Also, what do you do once you have 4-5 shell scripts at the root of your project? I find it gets messy quickly. I need a solution for this.
Put them in a folder! I see "tools" used commonly for dev/build scripts
Write a Python script instead? Easily cross platform. Nice libraries for CLI args. Easy to debug with a real debugger. Pretty nice?
I'd take php over python any day.
Everyone has their favorite python modules they like to use in scripts, half of them are not built or wrong version for whatever current distro I'm in, so I install stuff with pip, then something with requirements.txt breaks because of wrong pytorch version, I start reading about envs, much crying.
At least with bash or make nobody expects you to provide external modules/libraries
I’ve never so much as looked at a Php script in my life. I’d have to ask ChatGPT how to even run one.
A build script should work with vanilla out the box Python. No extra modules needed. I mean if you can assume vanilla bash tooling then vanilla Python is perfectly fine.
If there’s some Python library you really want then add it to repo. Easy peasy.
If you like Makefiles you should try Scons: https://scons.org/
Despite its age, my first and only encounter with it was in building godot. I was impressed from the user side. (Until, due to godot's dev policies (which might have changed by now) and not the fault of scons, a git pull resulted in a broken build even with a scons --clean. (Issue was some generated files had their parents removed by some commit, and the generated files were marked to not be cleaned by scons for some windows reason I think. Solution was to just delete them or do a git clean.)) But when I looked at their scons files, and their proliferation into every subdirectory like .svn folders, eh... The simple cases are simple, sure, but that's the case with everything. I think I'd only use scons for a project approaching godot's complexity -- especially amount of build targets -- and language mix (i.e. mostly C++).
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'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".
busybox make is quite restricted, which is why I write for it.
Me too :)
me too
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.
I like Makefiles too.
Just not this one.
me too.
> 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.
I know this is not your main point, and you touched briefly on it but, cmake is absolutely terrible.
It is supposed to make the building process more straight forward and painless but what it brings to the table is
* Weird bugs: In one version of cmake would return the python version that I had to be 0.16 (????) and the only fix was to update the cmake version
* Messy Structure: Under the guise of giving freedom to the person designing their build with no real enforcement of any rules, in any way, people can write their own absolute craptastic version of cmake scripts which really really is going to make you lose your mind (mind you some people leverage it but it is the exception not the rule)
* Opaque process: Due to the fact that the structure can be messy you are never really quite sure of what it is doing and which compile flags are effectively fed to the compiler as well as sometimes totally ignoring the library you explicitly ask it to use and trying to find another one...
OK maybe this is a bit superlative, but unfortunately for me, reflects well my experience with using cmake and feels like an extra item between me and getting things working painlessly... But I might have been doing it wrong.
The version of make which ships with Xcode is old (as Apple has stopped updating GPL software in general, and hopefully new builds of GNU make are GPL3 anyway), but it is otherwise not in any way somehow tied to Xcode's toolchain: it is a normal copy of GNU make 3.81 which runs commands the same as any other copy of make (as you provide them, and using the path).
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.