121–130 of 144 posts
Earlier quoted context omitted.
Seeing people reinvent make every 10 years is very frustrating. Just learn make!
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.
Earlier quoted context omitted.
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
Why invoke it via make when it can invoke itself? It's just another dependency that's not needed in this scenario.
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?
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.
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.
Some system have GNU, some BSD.
> at least trivial to install
Then same for `just`, package manager have it.
Earlier quoted context omitted.
> But this can literally just be done in a simple shell script as well. Only if there's no dependencies. It's unusual that GP's type of usage has no dependencies.
When my shell scripts depend on another script ... they run the other script. Make definitely has its place, especially when dependencies get complex and parallel, but it's hardly necessary for simple cases. Once Make is needed, it's trivial to drop in and have it wrap the standalone scripts.
I hear you, but you're running the other script unconditionally. If it downloads something, it will download it every time you run the first script.
In this simple case, make runs the other script conditionally, so it need not run every time.
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…
Seeing people reinvent make every 10 years is very frustrating. Just learn make!
Earlier quoted context omitted.
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.
i always hated make. until i read the manual...
I'd love some minor tweak of Make to compare/cache with hashes instead of mtime. A worse-is-better Bazel if you will.