I adore Makefiles as they're a very simple way to create a higher level abstraction in my projects. It builds data and runs small bits of code, so I can concentrate on the business-level value. I haven't found a better/simpler way that good old Makefiles.
How I stopped worrying and loved Makefiles
101–110 of 144 posts
Re: How I stopped worrying and loved Makefiles
#102Unfortunately make's behaviour around dynamically setting variables/environment variables is insane and quickly leads you towards hairy eval commands with extremely tricky quoting & escaping.
I suggest using := as in `APP_URL := http://localhost` vs raw "=". The colon-equals format means "set value now", so it's easier to understand.
I've never used eval.
Make's use of Bash can lead to hairy quoting/escaping. I use Make as a "dumb high-level runner" and put any sort of intelligence, like conditionals or loops or networking, in lower-level scripts or programs.
Make is an orchestrator.
Re: How I stopped worrying and loved Makefiles
#103This pattern of usage always seems like abuse. When `make` is used as a glorified front-end to `bash` scriptlets, why not use `bash` directly instead of having two-level of scripting? See: https://blog.aloni.org/posts/bash-functional-command-relay/
It is abuse, but people love ergonomics more than they love reducing dependencies
Turns out software is for humans, mostly :)
Re: How I stopped worrying and loved Makefiles
#104I've gotten so used to using Makefiles with Go dev that for my other side projects with node, python, ruby, etc. I wrap the tools and commands I can't remember in a Makefile. A quick squizz after a few months away reminds me of how that environment works with building, testing, etc.
Re: How I stopped worrying and loved Makefiles
#105One issue I don't hear mentioned often is reuse. A task runner's tasks could be arbitrarily complicated, pulling in all sorts of dependencies of their own. This is less true for the traditional compile targets make was designed for. Because the things we do in a Makefile are pretty much always project local and don't get reused, it limits how much heavy lifting these tasks are likely to do for us. Whereas if you buil…
Build a CLI / complex task as part of your project, then invoke it via make. This pattern is much more about documenting and composing steps than implementing them
Re: How I stopped worrying and loved Makefiles
#106The "Simple Makefile for Python projects" exemplifies why I dislike (ab)using make. It doesn't actually track deps properly, so venv doesn't get updated if requirements.txt changes, and nor does the dependency change tracking work properly for test target. To make it more correct you'd need bunch of .stamp files and/or globs, and even then it might be iffy. For lots of uses the simple file mtime based change/dep tracking is just too crude, and phony targets are largely an antipattern.
For script-running just is great, for full dep tracking build tool something like buck2 is an improvement.
The one place where make shines is when your workflow is truly file-based, so all steps can really be described as some variations of "transform file A to file B".
Re: How I stopped worrying and loved Makefiles
#107If you’re really looking for a tool to collect small steps/script I highly recommend you check out the ‘just’ cli tool. It’s completely replaced our use of Make and the syntax is much easier.
I've always wanted to use one of those, but you have to convince the other developers on your team to use it as well. Make is a relatively easy sell because it's on pretty much every system or at least trivial to install and has decades of reputation.
This is why I'm uninterested in just. I'd rather just use make than add another dependency.
Re: How I stopped worrying and loved Makefiles
#108Earlier quoted context omitted.
GNU Make gives me: - tab completion of targets - automatic dependency execution - automatic entry points between every task - result caching - parallel execution Yes, it’s possible to do all of this by hand in shell scripts. But why would I, when Make is ubiquitous and battle-tested?
Tab completion of targets is usually done by a separate package, not by GNU make itself: bash-completion.
Yes, that's true. But it is "on-by-default" for 95% of desktop Linux machines, with no special action needed.
Re: How I stopped worrying and loved Makefiles
#109Earlier quoted context omitted.
Tab completion of targets is usually done by a separate package, not by GNU make itself: bash-completion.
Yes, that's true. But it is "on-by-default" for 95% of desktop Linux machines, with no special action needed.
Its on until you try to tab-complete a filename that is created through make but the completion script can't detect it at which point the entire bash-completion package is uninstalled.
Re: How I stopped worrying and loved Makefiles
#110Make is excellent if you use it properly to model your dependencies. This works really well for languages like C/C++, but I think Make really struggles with languages like Go, JavaScript, and Python or when your using a large combination of technologies.
I've found Earthly [0] to be the _perfect_ tool to replace Make. It's a familiar syntax (combination of Dockerfiles + Makefiles). Every target is run in an isolated Docker container, and each target can copy files from other targets. This allows Earthly to perform caching and parallelization for free, and in addition you get lots of safety with containerization. I've been using Earthly for a couple of years now and I love it.
Some things I've built with it:
* At work [1], we use it to build Docker images for E2E testing. This includes building a Go project, our mkdocs documentation, our Vue UI, and a ton of little scripts all over the place for generating documentation, release notes, dependency information (like the licenses of our deps), etc.
* I used it to create my macOS cross compiler project [2].
* A project for playing a collaborative game of Pokemon on Discord [3]
IMO Makefiles are great if you have a few small targets. If you're looking at more than >50 lines, if your project uses many languages, or you need to run targets in a Docker container, then Earthly is a great choice.
[0]: https://earthly.dev/
[1]: https://p3m.dev/
[2]: https://github.com/shepherdjerred/macos-cross-compiler
[3]: https://github.com/shepherdjerred/discord-plays-pokemon