> 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

> 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 This means "whenever bar has been updated, create or recreate foo by running baz". You run it with "make foo", and make will run "baz" by default in "sh". 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 With this, when you run "make build", it'll only do "yarn install" if node_modules's last-modified timestamp is older than both package.json and yarn.lock. The touch is there to mark it updated for the next time you run "make build", so it knows it doesn't have to do anything. Normally you wouldn't have to do that but make assumes the commands given will update the file, and "yarn install" won't necessarily update the directory's last-modified time. 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 ...which appears to be how OP uses it.