Technically all of these make targets look for files by the names of the targets. Each one should really be defined as .PHONY.
That said, I used to write makefiles like this all the time, but have since switched to just and justfiles in recent years which make this the default behavior, and is generally simpler to use. Things like parameters are simpler.
I kinda like these make-ish systems, but they all have one problem: Make is already on any Linux and Mac, and is pretty easy to get on Windows as well. (It’s a real pity they don’t include it in the Git Bash!) Just using the lowest common denominator is a big argument for Make IMO.
You have to handle dependencies either way to build a project - what’s one more tiny executable?
This criticism might make sense for some non-vim editor because you might have to ssh into a remote location where you can’t install stuff. But if you should be able to build a project and thus install its required dependencies, then you might as well add one additional word to the install command.
On Windows if you don't use WSL, Cygwin gets you 95% of the way there. I've been using it for decades to develop CLI tools and backbends in Python and a few other languages. You learn the quirks in about 1 month, add some tooling like apt-cyg and map C: to /c and you're off to the races.
A big mistake Make has is mixing phony and file targets in the same namespace. They should be distinguishable by name, e.g. phony targets start with a : or something.
yeah just is really cool but it's not really commonly installed so that's kind of annoying.
i feel like we're due for some kind of newfangled coreutils distribution that packages up all the most common and useful newfangled utilities (just, ripgrep, and friends) and gets them everywhere you'd want them.
But I want please, ag and friends!
The "problem" with this kind of package is that everybody wants something else. And the chances that they get a part of the default MacOS or Windows install (or even part of the XCode command line tools or Plattform SDK (or whatever that is called now)) is quite small.
I like `asdf` a lot for this, but I actually don't use it for either of those examples (though it does have plugins for them). Ripgrep is in most package repos by now and all my dev machines have a Rust toolchain installed so I can build and install `just` from source with a quick command.
Sure, really though I don't understand why installing a single binary which is available from several easy to use package managers somehow becomes an insurmountable barrier for people when `just` is involved. "If it's not already on my system I can't use it" seems like an absurd limitation to place on your projects.
Please talk to security. My machine is locked down so tight I need a director (or higher) override to get anything not in the default distribution or "blessed" by security installed, and I can't even be the one to install it. May you never have to work at The Enterprise. It sucks!
At that point wouldn't you "just" download the source and compile locally? Since you presumably could compile stuff. Add a 'bin' folder in your home directory to your PATH and enjoy.
That sucks for sure, I did work a giant enterprise for a few years and it was plenty painful but not that bad at least. Well maybe it was that bad, because we didn't use make either, everything had to go through Jenkins and nobody bothered with anything for local development beyond an occasional `build.sh` somewhere in the project. Simply push your code when you think it's done and wait 30 minutes to get the next set of linter errors.
oh i have no problem at all installing stuff in my own environments, i'm all about having cool new tooling -- it just starts to get a little rude to ask others to do so in order to use something you're distributing (and therefore absent coreutils-ii-electric-boogaloo installed everywhere, i'm much more likely to reach for make, unfortunately).
Maybe it's different kinds of projects then. For most of what I work with distribution would have nothing to do with the build system in the repo, only people who would ever have to deal with it are other contributors that likely have some environment setup to do regardless.
Meanwhile gradle people are like: just run these included gradlew or gradlew.bat files, they'll download the actual gradle from somewhere online, pollute some folders in your home dir, and then execute the build stuff.
I notice just has some pre-built binaries that could be used for the same thing. I find it a little beyond rude what gradle normalized, but hey, it "works", and it removes the source of friction that's present any time you violate the principle of least surprise with your choice of build tool.
The reason why Gradle needs this junk in the first place is that they aggressively change and deprecate APIs. Tried to build a 6 year old project today and of course nothing works. Gradle wrapper proved pretty useful here. Make, on the other hand, has maintained almost perfect compatibility since it's inception.
I don't understand why Gradle doesn't just provide the wrapper for download. They do provide the checksums [0], so it's not like the wrapper is customized for each repo or anything, but to download it you have to download the full distribution, extract the archive to extract the archive to extract the archive and run Gradle to run Gradle.
The properties file specifying the version and checksum is great, but we shouldn't need millions of identical copies of the binary itself checked into every repo.
That said, I used to write makefiles like this all the time, but have since switched to just and justfiles in recent years which make this the default behavior, and is generally simpler to use. Things like parameters are simpler.
https://github.com/casey/just