4 ms·

> Make's core purpose is to execute commands, isn't it? How was it not designed to execute commands? Some people on HN believe that if you use make primarily a

> Make's core purpose is to execute commands, isn't it? How was it not designed to execute commands? Some people on HN believe that if you use make primarily as a task runner that you're doing it wrong and should use something else. I don't agree. Most users are using multiple aspects of make: as a task runner and as something that handles the dependency graph when building something digital. As a web developer, I used npm scripts, grunt, gulp, etc. to manage web builds but now I only use make and have gotten off the merry-go-round of web build tools.

TheSoftwareGuy 3y ago
What’s the point of using another tool to manage your shell scripts though? Why not just use shell scripts
- alwillis 3y ago
  > What’s the point of using another tool to manage your shell scripts though? Why not just use shell scripts. When you create a Makefile, you're describing a dependency graph of what depends on what and the order tasks need to take to produce a particular set of digital artifacts--you're not writing shell scripts. Turns out there are all kinds of edge cases and foot guns that make handles for you that you'd otherwise have to deal with if you wrote a bespoke shell script. Plus make is battle tested and has been around since the dawn of Unix--there's literally no build scenario it can't handle. I hadn't used make until a few years ago but it's been one of the best investments I've made in my workflow.
  - jcelerier 3y ago
    > there's literally no build scenario it can't handle. Well except this little case where some files or folders in your paths have spaces in them...
- Izkata 3y ago
  Makefiles coordinate your shell scripts, using a dependency tree you'd have to reimplement if you did it purely with shell scripts. For example: A) You have a recipe that installs dependencies if they're not up-to-date (such as "pip install"). B) You have a recipe that compiles stuff if it's not up-to-date; it's made to depend on A. C) "make" can be an interface recipe that depends on B and does nothing else. D) "make test" can be an interface recipe that depends on B, then runs tests. E) "make run" can be an interface recipe that depends on B, then actually runs the code / a webserver to interact with. Nowadays whenever I put one of these together there's 2 versions of A (one for python, one for node), 1+ versions of B (webpack build without watch, maybe others depending on the project), 3 versions of D ("test-js", "test-python", and "test" that does both, and each of them only requires the relevant parts of A and B). Makes it trivial to ensure you're up-to-date after a "git pull" without having to waste time waiting on things that don't need updating.

TheSoftwareGuy 3y ago

What’s the point of using another tool to manage your shell scripts though? Why not just use shell scripts

alwillis 3y ago
> What’s the point of using another tool to manage your shell scripts though? Why not just use shell scripts. When you create a Makefile, you're describing a dependency graph of what depends on what and the order tasks need to take to produce a particular set of digital artifacts--you're not writing shell scripts. Turns out there are all kinds of edge cases and foot guns that make handles for you that you'd otherwise have to deal with if you wrote a bespoke shell script. Plus make is battle tested and has been around since the dawn of Unix--there's literally no build scenario it can't handle. I hadn't used make until a few years ago but it's been one of the best investments I've made in my workflow.
- jcelerier 3y ago
  > there's literally no build scenario it can't handle. Well except this little case where some files or folders in your paths have spaces in them...
Izkata 3y ago
Makefiles coordinate your shell scripts, using a dependency tree you'd have to reimplement if you did it purely with shell scripts. For example: A) You have a recipe that installs dependencies if they're not up-to-date (such as "pip install"). B) You have a recipe that compiles stuff if it's not up-to-date; it's made to depend on A. C) "make" can be an interface recipe that depends on B and does nothing else. D) "make test" can be an interface recipe that depends on B, then runs tests. E) "make run" can be an interface recipe that depends on B, then actually runs the code / a webserver to interact with. Nowadays whenever I put one of these together there's 2 versions of A (one for python, one for node), 1+ versions of B (webpack build without watch, maybe others depending on the project), 3 versions of D ("test-js", "test-python", and "test" that does both, and each of them only requires the relevant parts of A and B). Makes it trivial to ensure you're up-to-date after a "git pull" without having to waste time waiting on things that don't need updating.