I really don’t like Make for the common use-cases it is being used for in the modern day, such as the Golang ecosystem or in many cases: creating docker files.
Make, at its core, is a tool that is meant to help you structure your dependencies for incrementally building things, but people use it as a glorified task runner simply due to the fact that it’s such a common build tool that it is nearly always installed if you have a development toolchain on your machine.
Go and docker already have incremental compilation built in, and docker doesn’t give definable artifacts so you can’t make other things depend on them either
It is a powerful tool, but the syntax is hideous and has more jagged edges than bash does, and we aren’t even using it in a way that justifies this. Makes me so frustrated for some reason.
Like everyone deciding to use a supercar to do farmwork.
`just` has some nice UX improvements over `make`. (e.g. doesn't require soft tabs, can list recipes out of the box, recipes can take command line arguments, supports .env files, can be run from any subdirectory).
I wish `just` had a way to capture the output of functions and act on them.
Without that, it is only a slightly more straight-forward Make that's way less likely to be installed on the system plus you have to take additional steps if you want shell completion for tasks.
Unless the question was, why do I have to mark targets as PHONY more generally.
In which case the answer is, you don't. You only do this when you want the recipe to always run when invoked, as opposed to the standard mode where invocation is conditional on the file being out-of-date.
I use it as a task runner with dependencies in python projects. In particular, it checks requirements files against the virtualenv to see if anything needs to be installed/updated, then all the tasks depend on that. If you're up-to-date the task runs immediately, if you're not it'll update for you.
> and docker doesn’t give definable artifacts so you can’t make other things depend on them either
Similar to how old projects have "make configure" to do some initial setup before "make" actually builds the project, I've done stuff on occasion where something like "make check" would pull information out of a system and create timestamped files in a scratch/ directory. Then the normal "make" would compare those files to the codebase to see if the system needed to be updated.
It is different from the first use I just mentioned, since you need two commands and it's not entirely automatic, but it's still simpler than checking each of the dependencies yourself.
I too use Make to install `node_modules` and `.venv`.
It is very convenient never having to ask oneself "Is my node_modules up to date?" after pulling or switching branches. I'll just let Make figure that out.
Yeah. And it's wildly misunderstood too, so you get random people writing and running `make clean test` stuff that inherently disagrees with itself, which can do all kinds of nonsense if your system isn't normal/clean/running on Thursday.
I do still use it for simple automation, because it's nice to have a language-agnostic way to do simple things. But once it grows beyond about a page of text it tends to become a real nightmare, and is nigh impossible for most people to help maintain... which is not at all helped by its absolute lack of clear best-practices or warnings when misconfigured, and poor meshing with many common systems (like source-modifying tools, e.g. gofmt).
It doesn't help that every guide starts out with
# so easy!
thing:
./build thing
When in reality you pretty much always need at least how this page ends, to be even slightly stable and maintainable:
# The final build step.
$(BUILD_DIR)/$(TARGET_EXEC): $(OBJS)
$(CXX) $(OBJS) -o $@ $(LDFLAGS)
# Build step for C source
$(BUILD_DIR)/%.c.o: %.c
mkdir -p $(dir $@)
$(CC) $(CPPFLAGS) $(CFLAGS) -c $< -o $@
# Build step for C++ source
$(BUILD_DIR)/%.cpp.o: %.cpp
mkdir -p $(dir $@)
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c $< -o $@
It's a horrifying bait-and-switch that a lot of people never fully learn their way through to the end.
In some ways yes. But there are absolutely differing degrees of inconsistency in a language.
Make is pretty darn far down the "deeply inconsistent and error-prone" side of things when you try to do anything correctly and reliably with it, particularly on multiple systems and across various implementations/versions. It survives because it's ubiquitous and just barely good enough.
In terms of task running specifically it does generally stay that simple for the likes of just.
The only complexity there is getting it installed on everyone's machine, but that's true of most tooling, even the common stuff given versions won't match. I solve that with Nix.
I do not rule out that one exists, but what tool looks simpler (I wanted to say ‘nicer’, but I think we should avoid ‘it looks ugly’ arguments; I think those largely are about familiarity) once you start building something from code written in multiple programming languages?
And what tool is as powerful that doesn’t have the ‘problem’ that a lot of people never learn it fully? (Why would I learn make or any other tool to the full? I browse its manual so that I know what it can do, and (hopefully) remember features exist when I need them, so that I can (often temporarily) learn them then)
Most of Make is quite reasonable. The simple stuff is clear and effective and a lot of the foundations are good (dependency order? only redo changes? great!)
It's the uncountable number of edge cases, lack of versioning/features (you can't declare what you need, you just succeed/fail/misbehave, often silently), massive massive problems dealing with entirely normal things in file paths like spaces, and more useful output than `make -d` for very common cases like "why am I rebuilding every time" / accidentally cyclic dependencies.
For starters.
Make does a lot right, but the amount of inconsistencies and friction to be reliable with it is truly absurd and unnecessary, and you need to go to extreme lengths to correctly handle them (e.g. cmake).
I have some copypasta that I stick in every makefile that has too many people abusing it blindly, yeah. It works but it's a real pain that there isn't a standard way to do it.
Which is an immediate consequence of make being built to make things, not run tasks. So it goes.
One obvious problem is that that isn't what `make clean test` does.
Order isn't guaranteed, and most clean targets won't have any dependency relationship with test targets, so it could test and then clean. Or interleave them (clean between test dependencies). Or run them both simultaneously if someone has set the -j flag, and then who knows what happens. It does often work out, but it depends on a lot of things.
It's a consequence of make making things, not running tasks. You've told it to make two things that you've said are completely unrelated to each other. Order doesn't matter there, so make is free to do whatever it wants.
---
Other than that, make's behavior when a target updates dependencies of another target which do not share dependencies can get extremely complicated, and often depends on execution order. Clean generally affects many/most, so it's sometimes very problematic to run with any other.
You might also have computed test dependencies at parse time based on what's on disk, which have changed unexpectedly due to clean deleting those files. That can cause `make clean test` vs `make clean` and then `make test` to behave completely differently. The latter is the only consistently safe option, and the only one where your intent will always match what make will do.
You are correct that Make is being abused because it's common. Me, I'm going to keep abusing Make vs bothering to find something supposedly better, that will then inject dependency startup problems I'd rather avoid.
Yes, abusing Make the way I and many others do is not the ideal use case, but it works just fine. It's good enough at being a task manager.
That's a fine opinion, but I haven't found a more widely available tool to describe a project "recipe", where project is written in one or more, of many possible languages
* Snakefile -> requires installation
* bash -> macOS is now ZSH. (Is bash a better choice than Make?)
The Makefile is going to be running external commands, no? So you still have the same problem (what are those external commands written in?) - whatever the answer to that question is, your task runner could be written in as well, probably.
At least, that's how I prefer to do it. A project that's heavy JS? Use a JS task runner. Heavy python? Python task runner. Heavy shell? And so on.
Sure but if a developer already has a JS runtime and they don't have Make installed, you've added unnecessary friction to the development process.
I hate JS as much as the next guy, but if I'm developing in JS, I use a JS task runner. Even a simple one. There's not much to "keep up with" IMO - they are quite easy to create and use, if the common/popular ones are missing features or move too fast for you.
But is there not a "minimal Makefile" type of subset that you can use that appears really clean and tidy? My Makefiles are super basic and are basically task runners. Perhaps there are traps I have not fallen into but I value that I can count on them working on whatever distro I run in 5 years time.
I always include Makefiles as a way of documenting useful (short) tasks for developers that are onboarding to projects. It gives them confidence in their ability to pick things up quickly. Whether or not they want to actually use make is up to them, but it’s one more thing they can reference.
I have long held similar opinions on make, and I've recently started using mage[0] in more and more go projects and have been happy with the result.
It's more task-oriented, the way people tend to write Makefiles with .PHONY rules, but it's all in go. It can be bootstrapped just with go too, and comes with some utilities to do make-like incremental builds if you need to.
Couldn't you have achieved this even more simply by using make with a go shell?
Btw, from the linked page:
> Makefiles are hard to read and hard to write. Mostly because makefiles are essentially fancy bash scripts with significant white space and additional make-related syntax.
Wait what? What does bash have to do with anything? Mage may well be amazing, but it doesn't sound like this person knows make that well at all. Which makes me think they're simply trying to reinvent the wheel -- in 'go'.
> Couldn't you have achieved this even more simply by using make with a go shell?
Make is still really about file to file transformations, and `go` already wraps up all of the behavior one would normally use make for. Plus you need make + a shell + go, vs. mage where all that's needed is go.
I can't speak for the author, but I assume they're reacting to how Makefiles tend to be used in go projects and not how make works generally.
I looked at both and came away thinking mage was more convenient for go-only projects. Just looked good and I would probably pick it for something that wasn't go-only (if make didn't make sense instead).
Agree, though it can be handy for sort of non-standard dependency stuff. Like if you need to pull some thing with curl before a build, and you want "curl succeeded (exited zero)" to be a pre-requisite for that build. It's often less work to get a Makefile to do that than a script, or the make-like things that come with some other languages.
Maybe not the best example, but if you have a project with several weird things like that, make is often easier.
I do, however, like having some of the amenities of a task runner without bringing in the "cruft" that's suited toward incremental builds. I like using Just (https://just.systems/) for those cases.
go-task is a very good task runner. Better than “just" IMO. I am now using go-task with every project. Right after creating the gitignore, I create the Taskfile.
I take the other side of this and find that it being so useful its use as a task runner just means make is really awesome. Even when “misused” it’s super useful.
That being said I really do like this article. I want to learn how to use make properly.
I really don’t like Make for the common use-cases it is being used for in the modern day, such as the Golang ecosystem or in many cases: creating docker files.
Make, at its core, is a tool that is meant to help you structure your dependencies for incrementally building things, but people use it as a glorified task runner simply due to the fact that it’s such a common build tool that it is nearly always installed if you have a development toolchain on your machine.
Go and docker already have incremental compilation built in, and docker doesn’t give definable artifacts so you can’t make other things depend on them either
It is a powerful tool, but the syntax is hideous and has more jagged edges than bash does, and we aren’t even using it in a way that justifies this. Makes me so frustrated for some reason.
Like everyone deciding to use a supercar to do farmwork.