3 ms·

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.

> 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.