3 ms·
i am an enthusiastic user of the probable antipattern of a makefile that is 90% phony targets. For whatever reason, a makefile full of little baby shell script
by hprotagonist 6y ago
i am an enthusiastic user of the probable antipattern of a makefile that is 90% phony targets.
For whatever reason, a makefile full of little baby shell scripts that are wired together seems cleaner and tidier and overall nicer to me.
Even ones that in no way at all ever depend on anything like a build state or looking to see if files have changed or whatever.
`make <action>` as the front-end to automate common tasks in my projects seems nicer than 15 shell scripts littering the top level of the repo, even if it is grossly underusing what make is capable of.
- aequitas 6y agoI was "converted" away from shell script to Makefile project management years ago by a formet co-worker and I'm still thankful he persisted in convincing me. Makefiles can be horrendous when you encounter them in C projects, with all the templating and generation and what not. But just a single Makefile at the project root with phony targets for all common tasks is a godsend. One pet peeve of mine is to make `make` the only requirement to bootstrap a project dev environment from scratch. Since make is so ubiquitous you can pull in just about any requirement and dependency with clever use of targets, order only prerequisites, and files.
- kreetx 6y agoI've just started learning makefiles - how would you say they are better from a regular bash file full of fumctions? I.e is it the "declarativeness" and it being a convention.
- aequitas 6y agoIndeed, declerativeness and conventions but also dependency resolving and ubiquity are the main plusses for me. Bash scripts used for these tasks tend to accrue a lot of boilerplate and every script has it's own conventions. So every time you need to debug them you need to debug a lot of code. With make every target can be it's own little isolated piece of code with input and output which makes reasoning about them a lot easier. A few tips when learning makefiles: terminology[0]: it's a lot easier to find answers if you know what it's called what you are searching for. Automatic Variables[1]: learn these by heart, and the way they allow DRY targets. If you have a dependecy that is not a file you can use a dot prefixed file as a proxy. [0] https://www.gnu.org/software/make/manual/html_node/Rule-Syntax.html https://www.gnu.org/software/make/manual/html_node/Rule-Synt... [1] https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html https://www.gnu.org/software/make/manual/html_node/Automatic...
- gumby 6y agoIf you just want to build something, perhaps it doesn't matter much. But when you are developing, typing "make" will rebuild the file you just edited plus anything that depends on the contents of that file (assuming a well written Makefile, which is not that hard to write for most cases). Trying to make that work in a bash script would involve lots of manually written tests, which would be easy to get wrong / get out of sync.
- jordwest 6y agoYou might like justfiles[1]. They’re designed pretty much on this philosophy. `just` doesn’t have the ubiquitous availability of `make`, but I’ve found it’s much more user friendly for this use case, especially with the documentation features and ability for commands to accept arguments. [1] https://github.com/casey/just https://github.com/casey/just
- aequitas 6y agoLooks interesting, just gave it a try converting a simple Makefile. But it seems like Just does away with file targets and file dependencies as a whole? As far as I can tell there is no way to skip dependencies that are already fulfilled?