12 ms·

How I stopped worrying and loved Makefiles

227 points by ___timor___ 2y ago

DeathArrow 2y ago
$ make love make: ** No rule to make target `love'. Stop.
unmdplyr 2y ago
Even the slightest attempt at guessing the host system or searching for tools present on a system will quickly convert this into a blog article earnestly begging for deep societal changes and analyses the inevitable marching of time.
- banish-m4 2y ago
  Hahaha. Yeap. And project dependency analysis and library feature detection quickly demand the GNU variant, autotools (gasp!), clunky scripts, or something else. Use make for simple things and simple things only.
  - patrickmay 2y ago
    Eric S. Raymond has a new project to eliminate the need for autotools: https://gitlab.com/esr/autodafe https://gitlab.com/esr/autodafe It appears to give the benefits of autotools with the simplicity of make.
- jimbokun 2y ago
  The real reason container systems like Docker became so popular.
  - einpoklum 2y ago
    the real _and unfortunate_ reason system like Docker became so popular: Caving in to the problem and creating endless replication and mess.
- tomjen3 2y ago
  Yeah. Which is why I wouldn't implement that in the first place - I come down hard on the idea that you should ship your dependencies, have them in a standard place or use a third-party resolution system (like every vaugely modern setup does. C#, Python, Ruby, Node, Rust even Java all understand that this is not optional anymore). Its a code smell to me when your build system starts to become too complicated and not fit on a screen.
  - ReleaseCandidat 2y ago
    You do know that there is software that runs on more than one version of Linux (or even on a *BSD, MacOS or Windows), works with more than a single version of a compiler,...?
    - tomjen3 2y ago
      Thats only really a problem for C/C++, which I have had the misfortune to make build systems for. The solution is not to ship complicated and bug infested build systems, it is to fix the dependency problem in the same way any other language has done so far and until we do this, ship the dependencies with the program. And if you aren't making a GUI and don't need to target Windows, just wrap it in Docker, which enforces a functional dependency system and means you can ship your dependencies.
      - ReleaseCandidat 2y ago
        > Thats only really a problem for C/C++ Even if that would be true, still every language that isn't C (or JS in the browser) needs to link or build against some C (or Fortran), which results in more or less working solutions on how to integrate with or build C sources. Of course you may not see that (as long as it works), because somebody else has wrapped that up in a package (or whatever) for your language of choice, but somebody has to do that. > ship the dependencies with the program. My post should have been the answer to this argument: this is not possible for example when "shipping" the source for a cross-platform library. Or a cross-platform end-user program/app. Or just about anything which isn't "just" some web-backend or a server of some kind. Does that mean _you_ need a complicated (I'd call that "working for anything but the most basic stuff") build-system? No. I am a bit puzzled by this phrase: > The solution is not to ship complicated and bug infested build systems, it is to fix the dependency problem in the same way any other language has done so far But any other language than C or C++ (sadly, _way_ less than "any other") solves that by using a complicated and bug infested build system(s) and package manager(s) or a combination of both.
banish-m4 2y ago
For simple things, make is fine. It does file caching and the GNU tool does parallel concurrency. For anything needing light-to-moderate software configuration management, cmake is readily available and simple. If you're running a Google then you're using a build and DVCS that make use of extensive caching, synthetic filesystems, and tools that wrap other tools. I won't say what not to use. ;)
lessbones 2y ago
tell me you've never seen Dr. Strangelove without telling me you've never seen Dr. Strangelove
renewiltord 2y ago
Taskfiles are pretty cool. The tab/space things makes Makefiles painful for me.
Mister_Snuggles 2y ago
My favourite (ab)use of `make` is as a batch runner: https://news.ycombinator.com/item?id=32441602 https://news.ycombinator.com/item?id=32441602 This (ab)use of `make` runs multiple times a day, every day, and works perfectly every time. The inspiration of this was an (ab)use of `make` as a way to paralellize Linux system startup: https://web.archive.org/web/20110606144530/http://www.ibm.com/developerworks/linux/library/l-boot/index.html https://web.archive.org/web/20110606144530/http://www.ibm.co...
- matheusmoreira 2y ago
  I (ab)use make to manage my dotfiles. https://github.com/matheusmoreira/.files/blob/master/GNUmakefile https://github.com/matheusmoreira/.files/blob/master/GNUmake... I'm surprised at how well this thing works every time I use it. I even blogged about it. https://www.matheusmoreira.com/articles/managing-dotfiles-with-make https://www.matheusmoreira.com/articles/managing-dotfiles-wi... Recently made a tool that processes the make database and prints the phony targets and their dependencies: https://github.com/matheusmoreira/.files/blob/master/~/.local/bin/phony-targets https://github.com/matheusmoreira/.files/blob/master/~/.loca... I use it as a sort of makefile help command. Works surprisingly well too.
web3-is-a-scam 2y ago
I’ve replaced my Make usage mostly with taskfile.dev and/or Warp workflows/notebooks
keyle 2y ago
I use makefiles a lot as make-do but I must admit the syntax does my head in at times. If anyone has a good resource that teaches makefile progressively, I'd be interested. The main issue I have is that it goes from dead simple to pit of what the hell is happening with various things interacting with each others.
- throwaway290232 2y ago
  > If anyone has a good resource that teaches makefile progressively https://www.gnu.org/software/make/manual/make.html https://www.gnu.org/software/make/manual/make.html
- liveranga 2y ago
  https://makefiletutorial.com/ https://makefiletutorial.com/
- redact207 2y ago
  I just use copilot for this and bash scripting, which I both do very little of and forget the syntax
1oooqooq 2y ago
i always hated make. until i read the manual...
- pizzafeelsright 2y ago
  Now this sounds like wisdom. I'm going to read the French manual.
lifthrasiir 2y ago
Ninja is simple and fast, but intentionally limited in order to not be programmable. Make is powerful and versatile (especially the GNU variant) but has an arcane syntax and lots of pitfalls. I feel that there is a niche between make and ninja for the task runner.
- dragontamer 2y ago
  > I feel that there is a niche between make and ninja for the task runner. I think that's called CMake.
  - lifthrasiir 2y ago
    No, CMake is a compatibility layer on top of existing task runners like make and ninja. I don't want a compatibility layer, and also CMake has even more features than make.
    - qart 2y ago
      CMake is a (not the) correct answer according to the Ninja manual[1]. "Some explicit non-goals: convenient syntax for writing build files by hand. You should generate your ninja files using another program. This is how we can sidestep many policy decisions." The other options are here: https://github.com/ninja-build/ninja/wiki/List-of-generators-producing-ninja-build-files https://github.com/ninja-build/ninja/wiki/List-of-generators... [1] https://ninja-build.org/manual.html#_design_goals https://ninja-build.org/manual.html#_design_goals
      - lifthrasiir 2y ago
        It is entirely correct that Ninja is technically designed for a related but different problem. But you can write Ninja by hand with some restrictions (I have done so for example), so bring back some of those sidestepped decisions may still be worthwhile.
  - ryukoposting 2y ago
    As one of the unfortunate souls damned to using CMake regularly, I can confidently say that it is slower, less maintainable, and less intelligible than make.
frankwiles 2y ago
If 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.
- AceJohnny2 2y ago
  lol that's a purple link for me: https://github.com/casey/just https://github.com/casey/just
- kstrauser 2y ago
  Seconded. For all the million things we used Makefiles for besides compiling software, Just is much more ergonomic.
  - ___timor___ 2y ago
    Looks interesting.
- devsda 2y ago
  Agree. I should specifically mention their docs. The docs are easily approachable with plenty of clear and concise examples. I even have a pdf copy of the doc book for quick reference.
- srid 2y ago
  I've been using this on almost all of my projects, and am really pleased with it. Shell autocompletion is a nice bonus. If you also Nix, checkout `just-flake`: https://github.com/juspay/just-flake https://github.com/juspay/just-flake
- MrDresden 2y ago
  Have moved all my 'frontend' Makefiles to Just and couldn't be happier.
- ricardobeat 2y ago
  Came here to say the same. Make works fine, until it evolves into a web of commands and associated shell scripts, and then most users give up on trying to understand what is happening. Justfiles are much more manageable.
sam_bristow 2y ago
If you're going to use Makefiles as a top-level build wrapper you might be interested in self-documenting targets. https://marmelab.com/blog/2016/02/29/auto-documented-makefile.html https://marmelab.com/blog/2016/02/29/auto-documented-makefil...
- Groxx 2y ago
  I've been using this for a while now - it's fantastic, highly recommended for non-core-Unix-build-stuff. Just make `help` your default recipe and voila, a massive drop in people asking "how do I run tests in make" -> they probably tried to `make` already and it told them how.
  - ___timor___ 2y ago
    Great idea, added to my todo :)
- _benj 2y ago
  Great tip! Thanks for sharing :-)
- JonChesterfield 2y ago
  The punchline here is a help target that digs through your makefiles looking for comments: help: @grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}' I stumbled over .*? since ? usually means optional, but turns out it means lazy in this context. The $$ would be makefile escaping. Dropping the grep and changing the regex slightly, I just appended this to an overengineered makefile: # Help idea derived from https://marmelab.com/blog/2016/02/29/auto-documented-makefile.html # Prints the help-text from `target: ## help-text`, slightly reformatted and sorted .PHONY: help help: ## Write this help awk 'BEGIN {FS = ":.*#+"}; /^[a-zA-Z_*.-]+:.*## .*$$/ {printf "%-30s %s\n", $$1, $$2}' $(MAKEFILE_LIST) | sort Very nice idea, thanks for sharing it!
  - konfekt 2y ago
    Which make version does the latter command use? For GNU make 4.2.1 on Linux, I hade more luck with something along the lines of @awk '/^[a-zA-Z_-]+:[^#]*## .*$$/ {match($$0, /## (.*)$$/, arr); printf "\033[36m%-30s\033[0m %s\n", $$1, substr($$0, RSTART+3)}' $(MAKEFILE_LIST)
yboris 2y ago
I don't like makefiles, but I've been enjoying justfiles: https://github.com/casey/just https://github.com/casey/just
matheusmoreira 2y ago
GNU Make is a surprisingly lisplike language. At some point I realized it had an eval function which I could use to metaprogram it. This actually ruined one of my projects, I got so lost trying to create the perfect makefile system that nothing short of a rewrite would fix it. As a side effect, I finally understood what autoconf's purpose was.
- jdougan 2y ago
  You can build Gnu Make so it can work with Guile Scheme.
throwaway290232 2y ago
Makefiles fill that great need for a high-level 'scripting DSL', where you have a lot of different programs (or scripts), with a loose set of dependencies or order of operation, and you want a very simple way to call them, with some very simple logic determining the order, arguments to pass, parallelization, etc. Their ubiquity on all platforms makes it even easier to use them. I much prefer Make to alternatives like Just or Taskfile. Besides the fact that more people know Make, Make actually has incredibly useful functionality that alternatives remove 'for simplicity', but then later you realize you want that functionality and go back to Make. Sometimes old tricks are the best tricks.
- smackeyacky 2y ago
  Seeing people reinvent make every 10 years is very frustrating. Just learn make!
  - VS1999 2y ago
    Practically any language will do for running a set of tasks to compile a program. Unless you already love this "wheel" intimately, just learn a real language and use that.
    - lelanthran 2y ago
      > Practically any language will do for running a set of tasks to compile a program. Like? None of the mainstream languages have any sort of builtin for dependency resolution.
    - throwaway290232 2y ago
      [dead]
  - kbolino 2y ago
    Make is conceptually great but brings a lot of legacy baggage. You often need to set up .PHONY targets, reset .SUFFIXES, and/or set MAKEFLAGS += --no-builtin-rules. There's also dollar-symbol variables (which plague Perl and shell as well) which made lots of sense in the 1970s with teletypes but hinder readability today (what the hell was $@ again?).
akdor1154 2y ago
I'd love some minor tweak of Make to compare/cache with hashes instead of mtime. A worse-is-better Bazel if you will.
- JonChesterfield 2y ago
  This might be worth building into the makefile interpreter. Doing it in the makefiles themselves is quite difficult to get right and very messy.
- alextingle 2y ago
  This is better achieved with the compiler level tooling, rather than in Make. It's pretty easy to replace `cc` with a short script that runs the pre-compiler and compares the result with a cache. If the source code is kept tight, it doesn't yield much of a speed-up, though - precompiling hundreds of unnecessary headers can take a lot of time. Better to put some effort into moving unnecessary #includes out of header files. In fact, you can use your log of cache-hits to guide that work.
- legobmw99 2y ago
  I also wish I could make certain variables/flags part of the dependencies of a file, like if I have something with a lot of #defines that I really want to rebuild any time CPPFLAGS changes
IkemenSensei 2y ago
I learned to stop worrying about Makefiles and loved Rakefiles instead because they allow you to write Ruby code anytime you need to do slightly complex tasks.
- ___timor___ 2y ago
  Makefile or Vagrantfile. Ruby's syntax is perfect for custom DSLs.
alhirzel 2y ago
> on my system binary is only 16kB in size, I don't believe that.
- patrickmay 2y ago
  119k on MacOS.
TheRealPomax 2y ago
The fact that make is basically useless on Windows still makes it "not the first thing to try", to be honest. And it's rare to still see a project that can't be cross-platform, only lots that went "well my computer runs XYZ so I'm only compiling on that" =)
- alextingle 2y ago
  Make works just fine on Windows.
  - legobmw99 2y ago
    If you’re very careful with forward-vs-back slashes and your username isn’t “Firstname Lastname”, sure. But in practice there are tons of issues especially for non expert users
  - TheRealPomax 2y ago
    "Can be made to work", absolutely. "Works fine", gonna have to disagree. The hoops one needs to jump through for every single new project that uses Makefiles in some new and creative "works flawlessly on unixy systems, why aren't you on one of those?" are appreciably larger than zero.
Fire-Dragon-DoL 2y ago
What's the rationale for using makefiles as script runners over just having a directory with scripts inside? Not for compiling, just as script runner. I see this practice often and I haven't found a good reason
- shmerl 2y ago
  Likely a declarative way to specify dependencies. But not sure if make as a tool for that is the best option in general.
- omoikane 2y ago
  Dependency management and automatic parallelization (via `make -j`).
- Groxx 2y ago
  Dependency management, definitely. Loads of scripts don't work until X has been done, and X, Y, Z, and sometimes QWERTY have to be done first, and they take minutes and a ton of bandwidth so you don't want to do them unless you have to... ... and if your scripts do all that, they've basically rebuilt make, but it's undocumented and worse. (I say this as someone with LOTS of experience with make, and am not really a fan because I know too much and it's horrifying. But I dislike custom crippled versions even more.)
- mark_story 2y ago
  It can help abstract the differences you may have across projects. If you're on a team with many projects/repositories, having conventions across them all helps improve onboarding, cross-teamwork and promotes better dev ux. A really simple way to do this is make. It lets you have the common targets and convert them to the relevant target. This can become more useful as you write automation for CI and deployments for all your projects.
- blipvert 2y ago
  If scripts need particular arguments the make is a good place to record them. I use it quite a lot for automating deployments - if you want to Terraform up a VM: make colo1-fooserver01.vm Then if you want to run Ansible against it: make colo1-fooserver01 You don’t have remember or type all of the flags or arguments - just type make and hit tab for a list of the targets that you can build
nesarkvechnep 2y ago
I’m tired of seeing articles full of examples of .PHONY targets. Make works with the file system!
da-x 2y ago
This 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/ https://blog.aloni.org/posts/bash-functional-command-relay/
- deleted 2y ago
  [deleted]
- mickeyp 2y ago
  Because PHONY targets can do that, too, and without the needless manual work. Because a Makefile can still do Makefile things: PHONY targets depending on other PHONY targets, which so happens to depend on that one openapi json export you also create, which in turn depends on ... You can do that in Bash. And now you've reinvented Makefile, but poorly.
- lijok 2y ago
  It is abuse, but people love ergonomics more than they love reducing dependencies
  - kristjansson 2y ago
    Turns out software is for humans, mostly :)
  - toast0 2y ago
    If you use Make to build, and you use Make to deploy, it's good for ergonomics, and it's good for reducing dependencies. Certainly abuse, but hey.
- dalore 2y ago
  Because the Makefile also becomes a central place of what you can run in a project without having dozens of different shell scripts. You can comment on targets, depend on others. Makefile targets to restore, the build i18n files, etc I made a bash script that takes your Makefile and gives you a nice dialog menu for the targets that have comments. Works nicely as a self documenting project command menu. https://gist.github.com/oppianmatt/dcc6f19542b080973e6164c7108d9a5a https://gist.github.com/oppianmatt/dcc6f19542b080973e6164c71... https://private-user-images.githubusercontent.com/48596/326243991-0883a94d-e0d5-4aba-a20c-11e5aa4b7da6.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTQyOTU0ODYsIm5iZiI6MTcxNDI5NTE4NiwicGF0aCI6Ii80ODU5Ni8zMjYyNDM5OTEtMDg4M2E5NGQtZTBkNS00YWJhLWEyMGMtMTFlNWFhNGI3ZGE2LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA0MjglMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNDI4VDA5MDYyNlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTU2MTIxNGQ3MmY4MDVhY2FiMGQyMDYxNzA5ODk0ZWVmMDVmOTI1NDk1NTc4ZDA5MGQ4NzUzMjYxNTViYzg0NmUmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.ohlIJuSMKqirW6poVsN-gXChrw5sDRcPLewPJ0Emzd4 https://private-user-images.githubusercontent.com/48596/3262...
ceving 2y ago
Most "modern" build tools do ruin make. Recently I did this for Go: https://gist.github.com/ceving/edeb6f58429d552e8828a70640db3d6e https://gist.github.com/ceving/edeb6f58429d552e8828a70640db3... But it does not feel right.
jaza 2y ago
Thanks! That article demystified quite a bit of the magic of Makefiles for me. However, even after 10+ years of professional dev work during which I've regularly crossed paths with Makefiles, they still scare me, and I've still never written one from scratch myself. I cling to bash scripts, which I'm also a rookie at (or, for more complex cases, I write Python scripts, which I'm much more comfortable with). I guess one day I'll read the manual, and digest some tutorials, and actually learn make. But I've made it this far...
- lelanthran 2y ago
  > However, even after 10+ years of professional dev work during which I've regularly crossed paths with Makefiles, they still scare me, and I've still never written one from scratch myself. Make has its warts (look at when and what it was designed for, after all!), but I've found it much easier to write Makefiles than YAML-for-github-runners. If you're used to YAML, you get pleasantly surprised when using Make, which does execution of dependency trees in a more readable manner than most CI/CD YAML files do.
dissent 2y ago
One 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 built your our CLI in Python with Click or something, you would be able to make it a development dependency of your project. You can afford to invest in those tasks more because they'll be reused. The Just command runner has the same problem, but at least it's designed to be a task runner.
- kristjansson 2y ago
  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
  - dissent 2y ago
    Why invoke it via make when it can invoke itself? It's just another dependency that's not needed in this scenario.
    - nrclark 2y ago
      Make is leaner and more agile than a custom CLI. It takes no time to get started, and there is no boilerplate. Removing or adding steps is trivial, running shell commands is trivial, and hooking into the dependency graph is trivial. Parallelism is built-in, as is dependency resolution. Tab-completion is standard on most Linux distros. It's also better from an architectural separation perspective. Your custom CLI will have custom commands and flags, and probably will need to be called in some standardized way. Make is very good at calling your toolchain / build-system (whatever that might be) with the exact arguments that you want. And things like "make all" or "make clean" are muscle-memory for hundreds of thousands of developers. Why mix your custom tooling with the task of standardizing an entry point? I've had really great success over the years with the pattern of "some build system or another (cmake, bazel, autotools, etc) orchestrated by a top-level Makefile." It's simple, portable, and flexible. What's not to like, other than ugly syntax?
ris 2y ago
Unfortunately make's behaviour around dynamically setting variables/environment variables is insane and quickly leads you towards hairy eval commands with extremely tricky quoting & escaping.
- john-tells-all 2y ago
  I suggest using := as in `APP_URL := http://localhost 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.
john-tells-all 2y ago
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.
liampulles 2y ago
I'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.
zokier 2y ago
The "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".
- nrclark 2y ago
  My team uses Make to handle the top-level scripting for a Python development project, and it works great. It was pretty easy to set up the correct dependency relationships. Make is a powerful tool. You just have to understand how it thinks about the world, and adjust your own thinking a bit if needed. If you just want to have tasks that depend on other tasks, you don't need stamps, phony, or anything else. But what happens when you want to say "only rebuild my venv if requirements.txt changed"? that's a file dependency that you can reasonably express between requirements.txt and venv/bin/activate. And then all of a sudden, you're squarely in Make's wheelhouse.
shepherdjerred 2y ago
Make 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/ https://earthly.dev/ [1]: https://p3m.dev/ https://p3m.dev/ [2]: https://github.com/shepherdjerred/macos-cross-compiler https://github.com/shepherdjerred/macos-cross-compiler [3]: https://github.com/shepherdjerred/discord-plays-pokemon https://github.com/shepherdjerred/discord-plays-pokemon
wodenokoto 2y ago
I'm a bit unsure what this does better than just calling those few lines directly in a shell script.
xg15 2y ago
Obligatory reminder that the phrase "How I stopped worrying and loved X" was supposed to be a sign of insanity, not an endorsement of X.
JohnFen 2y ago
There is quite a lot to love about make! I still haven't seen an alternative that is substantially better, and most are worse in one way or another. My opinion may be a bit skewed by the fact that I write code that gets built on a variety of different platforms, though, and make is essentially universal. It lets me have a consistent build process regardless of platform. It's also very useful for automation that isn't related to building code.
lfmunoz4 2y ago
For people using make and vscode my plugin is a must have: https://marketplace.visualstudio.com/items?itemName=lfm.vscode-makefile-term&ssr=false#overview https://marketplace.visualstudio.com/items?itemName=lfm.vsco... It allows you to click above target to run target.
kevincox 2y ago
One minor tip is that you can define .PHONY multiple times. I find this much easier to manage because the .PHONY definition is right next to the target itself. .PHONY: foo foo: echo foo bar: barin cp barin bar .PHONY: baz baz: bar echo baz

227 points by ___timor___ 2y ago

$ make love make: ** No rule to make target `love'. Stop.

Even the slightest attempt at guessing the host system or searching for tools present on a system will quickly convert this into a blog article earnestly begging for deep societal changes and analyses the inevitable marching of time.

banish-m4 2y ago
Hahaha. Yeap. And project dependency analysis and library feature detection quickly demand the GNU variant, autotools (gasp!), clunky scripts, or something else. Use make for simple things and simple things only.
- patrickmay 2y ago
  Eric S. Raymond has a new project to eliminate the need for autotools: https://gitlab.com/esr/autodafe https://gitlab.com/esr/autodafe It appears to give the benefits of autotools with the simplicity of make.
jimbokun 2y ago
The real reason container systems like Docker became so popular.
- einpoklum 2y ago
  the real _and unfortunate_ reason system like Docker became so popular: Caving in to the problem and creating endless replication and mess.
tomjen3 2y ago
Yeah. Which is why I wouldn't implement that in the first place - I come down hard on the idea that you should ship your dependencies, have them in a standard place or use a third-party resolution system (like every vaugely modern setup does. C#, Python, Ruby, Node, Rust even Java all understand that this is not optional anymore). Its a code smell to me when your build system starts to become too complicated and not fit on a screen.
- ReleaseCandidat 2y ago
  You do know that there is software that runs on more than one version of Linux (or even on a *BSD, MacOS or Windows), works with more than a single version of a compiler,...?
  - tomjen3 2y ago
    Thats only really a problem for C/C++, which I have had the misfortune to make build systems for. The solution is not to ship complicated and bug infested build systems, it is to fix the dependency problem in the same way any other language has done so far and until we do this, ship the dependencies with the program. And if you aren't making a GUI and don't need to target Windows, just wrap it in Docker, which enforces a functional dependency system and means you can ship your dependencies.
    - ReleaseCandidat 2y ago
      > Thats only really a problem for C/C++ Even if that would be true, still every language that isn't C (or JS in the browser) needs to link or build against some C (or Fortran), which results in more or less working solutions on how to integrate with or build C sources. Of course you may not see that (as long as it works), because somebody else has wrapped that up in a package (or whatever) for your language of choice, but somebody has to do that. > ship the dependencies with the program. My post should have been the answer to this argument: this is not possible for example when "shipping" the source for a cross-platform library. Or a cross-platform end-user program/app. Or just about anything which isn't "just" some web-backend or a server of some kind. Does that mean _you_ need a complicated (I'd call that "working for anything but the most basic stuff") build-system? No. I am a bit puzzled by this phrase: > The solution is not to ship complicated and bug infested build systems, it is to fix the dependency problem in the same way any other language has done so far But any other language than C or C++ (sadly, _way_ less than "any other") solves that by using a complicated and bug infested build system(s) and package manager(s) or a combination of both.

banish-m4 2y ago

For simple things, make is fine. It does file caching and the GNU tool does parallel concurrency. For anything needing light-to-moderate software configuration management, cmake is readily available and simple. If you're running a Google then you're using a build and DVCS that make use of extensive caching, synthetic filesystems, and tools that wrap other tools. I won't say what not to use. ;)

lessbones 2y ago

tell me you've never seen Dr. Strangelove without telling me you've never seen Dr. Strangelove

renewiltord 2y ago

Taskfiles are pretty cool. The tab/space things makes Makefiles painful for me.

Mister_Snuggles 2y ago

My favourite (ab)use of `make` is as a batch runner: https://news.ycombinator.com/item?id=32441602 https://news.ycombinator.com/item?id=32441602 This (ab)use of `make` runs multiple times a day, every day, and works perfectly every time. The inspiration of this was an (ab)use of `make` as a way to paralellize Linux system startup: https://web.archive.org/web/20110606144530/http://www.ibm.com/developerworks/linux/library/l-boot/index.html https://web.archive.org/web/20110606144530/http://www.ibm.co...

matheusmoreira 2y ago
I (ab)use make to manage my dotfiles. https://github.com/matheusmoreira/.files/blob/master/GNUmakefile https://github.com/matheusmoreira/.files/blob/master/GNUmake... I'm surprised at how well this thing works every time I use it. I even blogged about it. https://www.matheusmoreira.com/articles/managing-dotfiles-with-make https://www.matheusmoreira.com/articles/managing-dotfiles-wi... Recently made a tool that processes the make database and prints the phony targets and their dependencies: https://github.com/matheusmoreira/.files/blob/master/~/.local/bin/phony-targets https://github.com/matheusmoreira/.files/blob/master/~/.loca... I use it as a sort of makefile help command. Works surprisingly well too.

web3-is-a-scam 2y ago

I’ve replaced my Make usage mostly with taskfile.dev and/or Warp workflows/notebooks

keyle 2y ago

I use makefiles a lot as make-do but I must admit the syntax does my head in at times. If anyone has a good resource that teaches makefile progressively, I'd be interested. The main issue I have is that it goes from dead simple to pit of what the hell is happening with various things interacting with each others.

throwaway290232 2y ago
> If anyone has a good resource that teaches makefile progressively https://www.gnu.org/software/make/manual/make.html https://www.gnu.org/software/make/manual/make.html
liveranga 2y ago
https://makefiletutorial.com/ https://makefiletutorial.com/
redact207 2y ago
I just use copilot for this and bash scripting, which I both do very little of and forget the syntax

1oooqooq 2y ago

i always hated make. until i read the manual...

pizzafeelsright 2y ago
Now this sounds like wisdom. I'm going to read the French manual.

lifthrasiir 2y ago

Ninja is simple and fast, but intentionally limited in order to not be programmable. Make is powerful and versatile (especially the GNU variant) but has an arcane syntax and lots of pitfalls. I feel that there is a niche between make and ninja for the task runner.

dragontamer 2y ago
> I feel that there is a niche between make and ninja for the task runner. I think that's called CMake.
- lifthrasiir 2y ago
  No, CMake is a compatibility layer on top of existing task runners like make and ninja. I don't want a compatibility layer, and also CMake has even more features than make.
  - qart 2y ago
    CMake is a (not the) correct answer according to the Ninja manual[1]. "Some explicit non-goals: convenient syntax for writing build files by hand. You should generate your ninja files using another program. This is how we can sidestep many policy decisions." The other options are here: https://github.com/ninja-build/ninja/wiki/List-of-generators-producing-ninja-build-files https://github.com/ninja-build/ninja/wiki/List-of-generators... [1] https://ninja-build.org/manual.html#_design_goals https://ninja-build.org/manual.html#_design_goals
    - lifthrasiir 2y ago
      It is entirely correct that Ninja is technically designed for a related but different problem. But you can write Ninja by hand with some restrictions (I have done so for example), so bring back some of those sidestepped decisions may still be worthwhile.
- ryukoposting 2y ago
  As one of the unfortunate souls damned to using CMake regularly, I can confidently say that it is slower, less maintainable, and less intelligible than make.

frankwiles 2y ago

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

AceJohnny2 2y ago
lol that's a purple link for me: https://github.com/casey/just https://github.com/casey/just
kstrauser 2y ago
Seconded. For all the million things we used Makefiles for besides compiling software, Just is much more ergonomic.
- ___timor___ 2y ago
  Looks interesting.
devsda 2y ago
Agree. I should specifically mention their docs. The docs are easily approachable with plenty of clear and concise examples. I even have a pdf copy of the doc book for quick reference.
srid 2y ago
I've been using this on almost all of my projects, and am really pleased with it. Shell autocompletion is a nice bonus. If you also Nix, checkout `just-flake`: https://github.com/juspay/just-flake https://github.com/juspay/just-flake
MrDresden 2y ago
Have moved all my 'frontend' Makefiles to Just and couldn't be happier.
ricardobeat 2y ago
Came here to say the same. Make works fine, until it evolves into a web of commands and associated shell scripts, and then most users give up on trying to understand what is happening. Justfiles are much more manageable.

sam_bristow 2y ago

If you're going to use Makefiles as a top-level build wrapper you might be interested in self-documenting targets. https://marmelab.com/blog/2016/02/29/auto-documented-makefile.html https://marmelab.com/blog/2016/02/29/auto-documented-makefil...

Groxx 2y ago
I've been using this for a while now - it's fantastic, highly recommended for non-core-Unix-build-stuff. Just make `help` your default recipe and voila, a massive drop in people asking "how do I run tests in make" -> they probably tried to `make` already and it told them how.
- ___timor___ 2y ago
  Great idea, added to my todo :)
_benj 2y ago
Great tip! Thanks for sharing :-)
JonChesterfield 2y ago
The punchline here is a help target that digs through your makefiles looking for comments: help: @grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}' I stumbled over .*? since ? usually means optional, but turns out it means lazy in this context. The $$ would be makefile escaping. Dropping the grep and changing the regex slightly, I just appended this to an overengineered makefile: # Help idea derived from https://marmelab.com/blog/2016/02/29/auto-documented-makefile.html # Prints the help-text from `target: ## help-text`, slightly reformatted and sorted .PHONY: help help: ## Write this help awk 'BEGIN {FS = ":.*#+"}; /^[a-zA-Z_*.-]+:.*## .*$$/ {printf "%-30s %s\n", $$1, $$2}' $(MAKEFILE_LIST) | sort Very nice idea, thanks for sharing it!
- konfekt 2y ago
  Which make version does the latter command use? For GNU make 4.2.1 on Linux, I hade more luck with something along the lines of @awk '/^[a-zA-Z_-]+:[^#]*## .*$$/ {match($$0, /## (.*)$$/, arr); printf "\033[36m%-30s\033[0m %s\n", $$1, substr($$0, RSTART+3)}' $(MAKEFILE_LIST)

yboris 2y ago

I don't like makefiles, but I've been enjoying justfiles: https://github.com/casey/just https://github.com/casey/just

matheusmoreira 2y ago

GNU Make is a surprisingly lisplike language. At some point I realized it had an eval function which I could use to metaprogram it. This actually ruined one of my projects, I got so lost trying to create the perfect makefile system that nothing short of a rewrite would fix it. As a side effect, I finally understood what autoconf's purpose was.

jdougan 2y ago
You can build Gnu Make so it can work with Guile Scheme.

throwaway290232 2y ago

Makefiles fill that great need for a high-level 'scripting DSL', where you have a lot of different programs (or scripts), with a loose set of dependencies or order of operation, and you want a very simple way to call them, with some very simple logic determining the order, arguments to pass, parallelization, etc. Their ubiquity on all platforms makes it even easier to use them. I much prefer Make to alternatives like Just or Taskfile. Besides the fact that more people know Make, Make actually has incredibly useful functionality that alternatives remove 'for simplicity', but then later you realize you want that functionality and go back to Make. Sometimes old tricks are the best tricks.

smackeyacky 2y ago
Seeing people reinvent make every 10 years is very frustrating. Just learn make!
- VS1999 2y ago
  Practically any language will do for running a set of tasks to compile a program. Unless you already love this "wheel" intimately, just learn a real language and use that.
  - lelanthran 2y ago
    > Practically any language will do for running a set of tasks to compile a program. Like? None of the mainstream languages have any sort of builtin for dependency resolution.
  - throwaway290232 2y ago
    [dead]
- kbolino 2y ago
  Make is conceptually great but brings a lot of legacy baggage. You often need to set up .PHONY targets, reset .SUFFIXES, and/or set MAKEFLAGS += --no-builtin-rules. There's also dollar-symbol variables (which plague Perl and shell as well) which made lots of sense in the 1970s with teletypes but hinder readability today (what the hell was $@ again?).

akdor1154 2y ago

I'd love some minor tweak of Make to compare/cache with hashes instead of mtime. A worse-is-better Bazel if you will.

JonChesterfield 2y ago
This might be worth building into the makefile interpreter. Doing it in the makefiles themselves is quite difficult to get right and very messy.
alextingle 2y ago
This is better achieved with the compiler level tooling, rather than in Make. It's pretty easy to replace `cc` with a short script that runs the pre-compiler and compares the result with a cache. If the source code is kept tight, it doesn't yield much of a speed-up, though - precompiling hundreds of unnecessary headers can take a lot of time. Better to put some effort into moving unnecessary #includes out of header files. In fact, you can use your log of cache-hits to guide that work.
legobmw99 2y ago
I also wish I could make certain variables/flags part of the dependencies of a file, like if I have something with a lot of #defines that I really want to rebuild any time CPPFLAGS changes

IkemenSensei 2y ago

I learned to stop worrying about Makefiles and loved Rakefiles instead because they allow you to write Ruby code anytime you need to do slightly complex tasks.

___timor___ 2y ago
Makefile or Vagrantfile. Ruby's syntax is perfect for custom DSLs.

alhirzel 2y ago

> on my system binary is only 16kB in size, I don't believe that.

patrickmay 2y ago
119k on MacOS.

TheRealPomax 2y ago

The fact that make is basically useless on Windows still makes it "not the first thing to try", to be honest. And it's rare to still see a project that can't be cross-platform, only lots that went "well my computer runs XYZ so I'm only compiling on that" =)

alextingle 2y ago
Make works just fine on Windows.
- legobmw99 2y ago
  If you’re very careful with forward-vs-back slashes and your username isn’t “Firstname Lastname”, sure. But in practice there are tons of issues especially for non expert users
- TheRealPomax 2y ago
  "Can be made to work", absolutely. "Works fine", gonna have to disagree. The hoops one needs to jump through for every single new project that uses Makefiles in some new and creative "works flawlessly on unixy systems, why aren't you on one of those?" are appreciably larger than zero.

Fire-Dragon-DoL 2y ago

What's the rationale for using makefiles as script runners over just having a directory with scripts inside? Not for compiling, just as script runner. I see this practice often and I haven't found a good reason

shmerl 2y ago
Likely a declarative way to specify dependencies. But not sure if make as a tool for that is the best option in general.
omoikane 2y ago
Dependency management and automatic parallelization (via `make -j`).
Groxx 2y ago
Dependency management, definitely. Loads of scripts don't work until X has been done, and X, Y, Z, and sometimes QWERTY have to be done first, and they take minutes and a ton of bandwidth so you don't want to do them unless you have to... ... and if your scripts do all that, they've basically rebuilt make, but it's undocumented and worse. (I say this as someone with LOTS of experience with make, and am not really a fan because I know too much and it's horrifying. But I dislike custom crippled versions even more.)
mark_story 2y ago
It can help abstract the differences you may have across projects. If you're on a team with many projects/repositories, having conventions across them all helps improve onboarding, cross-teamwork and promotes better dev ux. A really simple way to do this is make. It lets you have the common targets and convert them to the relevant target. This can become more useful as you write automation for CI and deployments for all your projects.
blipvert 2y ago
If scripts need particular arguments the make is a good place to record them. I use it quite a lot for automating deployments - if you want to Terraform up a VM: make colo1-fooserver01.vm Then if you want to run Ansible against it: make colo1-fooserver01 You don’t have remember or type all of the flags or arguments - just type make and hit tab for a list of the targets that you can build

nesarkvechnep 2y ago

I’m tired of seeing articles full of examples of .PHONY targets. Make works with the file system!

da-x 2y ago

This 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/ https://blog.aloni.org/posts/bash-functional-command-relay/

deleted 2y ago
[deleted]
mickeyp 2y ago
Because PHONY targets can do that, too, and without the needless manual work. Because a Makefile can still do Makefile things: PHONY targets depending on other PHONY targets, which so happens to depend on that one openapi json export you also create, which in turn depends on ... You can do that in Bash. And now you've reinvented Makefile, but poorly.
lijok 2y ago
It is abuse, but people love ergonomics more than they love reducing dependencies
- kristjansson 2y ago
  Turns out software is for humans, mostly :)
- toast0 2y ago
  If you use Make to build, and you use Make to deploy, it's good for ergonomics, and it's good for reducing dependencies. Certainly abuse, but hey.
dalore 2y ago
Because the Makefile also becomes a central place of what you can run in a project without having dozens of different shell scripts. You can comment on targets, depend on others. Makefile targets to restore, the build i18n files, etc I made a bash script that takes your Makefile and gives you a nice dialog menu for the targets that have comments. Works nicely as a self documenting project command menu. https://gist.github.com/oppianmatt/dcc6f19542b080973e6164c7108d9a5a https://gist.github.com/oppianmatt/dcc6f19542b080973e6164c71... https://private-user-images.githubusercontent.com/48596/326243991-0883a94d-e0d5-4aba-a20c-11e5aa4b7da6.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTQyOTU0ODYsIm5iZiI6MTcxNDI5NTE4NiwicGF0aCI6Ii80ODU5Ni8zMjYyNDM5OTEtMDg4M2E5NGQtZTBkNS00YWJhLWEyMGMtMTFlNWFhNGI3ZGE2LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA0MjglMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNDI4VDA5MDYyNlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTU2MTIxNGQ3MmY4MDVhY2FiMGQyMDYxNzA5ODk0ZWVmMDVmOTI1NDk1NTc4ZDA5MGQ4NzUzMjYxNTViYzg0NmUmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.ohlIJuSMKqirW6poVsN-gXChrw5sDRcPLewPJ0Emzd4 https://private-user-images.githubusercontent.com/48596/3262...

ceving 2y ago

Most "modern" build tools do ruin make. Recently I did this for Go: https://gist.github.com/ceving/edeb6f58429d552e8828a70640db3d6e https://gist.github.com/ceving/edeb6f58429d552e8828a70640db3... But it does not feel right.

jaza 2y ago

Thanks! That article demystified quite a bit of the magic of Makefiles for me. However, even after 10+ years of professional dev work during which I've regularly crossed paths with Makefiles, they still scare me, and I've still never written one from scratch myself. I cling to bash scripts, which I'm also a rookie at (or, for more complex cases, I write Python scripts, which I'm much more comfortable with). I guess one day I'll read the manual, and digest some tutorials, and actually learn make. But I've made it this far...

lelanthran 2y ago
> However, even after 10+ years of professional dev work during which I've regularly crossed paths with Makefiles, they still scare me, and I've still never written one from scratch myself. Make has its warts (look at when and what it was designed for, after all!), but I've found it much easier to write Makefiles than YAML-for-github-runners. If you're used to YAML, you get pleasantly surprised when using Make, which does execution of dependency trees in a more readable manner than most CI/CD YAML files do.

dissent 2y ago

One 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 built your our CLI in Python with Click or something, you would be able to make it a development dependency of your project. You can afford to invest in those tasks more because they'll be reused. The Just command runner has the same problem, but at least it's designed to be a task runner.

kristjansson 2y ago
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
- dissent 2y ago
  Why invoke it via make when it can invoke itself? It's just another dependency that's not needed in this scenario.
  - nrclark 2y ago
    Make is leaner and more agile than a custom CLI. It takes no time to get started, and there is no boilerplate. Removing or adding steps is trivial, running shell commands is trivial, and hooking into the dependency graph is trivial. Parallelism is built-in, as is dependency resolution. Tab-completion is standard on most Linux distros. It's also better from an architectural separation perspective. Your custom CLI will have custom commands and flags, and probably will need to be called in some standardized way. Make is very good at calling your toolchain / build-system (whatever that might be) with the exact arguments that you want. And things like "make all" or "make clean" are muscle-memory for hundreds of thousands of developers. Why mix your custom tooling with the task of standardizing an entry point? I've had really great success over the years with the pattern of "some build system or another (cmake, bazel, autotools, etc) orchestrated by a top-level Makefile." It's simple, portable, and flexible. What's not to like, other than ugly syntax?

ris 2y ago

Unfortunately make's behaviour around dynamically setting variables/environment variables is insane and quickly leads you towards hairy eval commands with extremely tricky quoting & escaping.

john-tells-all 2y ago
I suggest using := as in `APP_URL := http://localhost 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.

john-tells-all 2y ago

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.

liampulles 2y ago

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

zokier 2y ago

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

nrclark 2y ago
My team uses Make to handle the top-level scripting for a Python development project, and it works great. It was pretty easy to set up the correct dependency relationships. Make is a powerful tool. You just have to understand how it thinks about the world, and adjust your own thinking a bit if needed. If you just want to have tasks that depend on other tasks, you don't need stamps, phony, or anything else. But what happens when you want to say "only rebuild my venv if requirements.txt changed"? that's a file dependency that you can reasonably express between requirements.txt and venv/bin/activate. And then all of a sudden, you're squarely in Make's wheelhouse.

shepherdjerred 2y ago

Make 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/ https://earthly.dev/ [1]: https://p3m.dev/ https://p3m.dev/ [2]: https://github.com/shepherdjerred/macos-cross-compiler https://github.com/shepherdjerred/macos-cross-compiler [3]: https://github.com/shepherdjerred/discord-plays-pokemon https://github.com/shepherdjerred/discord-plays-pokemon

wodenokoto 2y ago

I'm a bit unsure what this does better than just calling those few lines directly in a shell script.

xg15 2y ago

Obligatory reminder that the phrase "How I stopped worrying and loved X" was supposed to be a sign of insanity, not an endorsement of X.

JohnFen 2y ago

There is quite a lot to love about make! I still haven't seen an alternative that is substantially better, and most are worse in one way or another. My opinion may be a bit skewed by the fact that I write code that gets built on a variety of different platforms, though, and make is essentially universal. It lets me have a consistent build process regardless of platform. It's also very useful for automation that isn't related to building code.

lfmunoz4 2y ago

For people using make and vscode my plugin is a must have: https://marketplace.visualstudio.com/items?itemName=lfm.vscode-makefile-term&ssr=false#overview https://marketplace.visualstudio.com/items?itemName=lfm.vsco... It allows you to click above target to run target.

kevincox 2y ago

One minor tip is that you can define .PHONY multiple times. I find this much easier to manage because the .PHONY definition is right next to the target itself. .PHONY: foo foo: echo foo bar: barin cp barin bar .PHONY: baz baz: bar echo baz