Hacker News new | ask | show | jobs
by shoo 1401 days ago
I've worked on a few projects that apply this pattern of using a Makefile to define and run imperative commands. A few people develop the pattern independently, then it gets proliferated through the company as part of the boilerplate into new repositories. It's not a terrible pattern, it's just a bit strange.

For many junior colleagues, this pattern is the first time they've ever encountered make -- hijacked as some kind of imperative command runner.

It's quite rare to run into someone who is aware that make can be used to define rules for producing files from other files.

I find it all a bit odd. Of course, no-one is born knowing about middle-aged build tools.

2 comments

> It's quite rare to run into someone who is aware that make can be used to define rules for producing files from other files.

Is it, though?

That's literally what Make does as part of its happy path.

GNU Make even added support for pattern rules, as this use case is so pervasive.

What do you think people think make is about?

oh i agree, that's why i find the situation odd!

i'm talking working on projects with people whose first encounter with make is in a project where someone else has defined a Makefile to wrap imperative actions, e.g. `make run-unit-tests`, `make deploy`. If they think about make at all, there's a good chance they think make is for performing imperative actions, and has nothing specifically to do with producing files from other files using rules and a dependency graph, or the idea of a target being a file, or a target being out of date.

This is what I do for all non-rust projects. I knew what it was supposed to do, but wow if it took me forever to figure out how to do it (the connection between rule name and file name is really poorly documented in tutorials, probably should've just read the man page)
Yeah, I did this too. It's not that surprising considering that typically end-users only interact with phony targets (all, clean, install, etc).