31–40 of 58 posts
It's interesting, but I can't help but think that by the time you're adding `.PHONY` after most rules, you're not using the right tool for the job. (I generally find a small set of shell scripts work, or just three or four rules in the package.json file I can access with `npm run`).
Earlier quoted context omitted.
It's not an exaggeration when you inevitably end up chaining them. The overhead adds up very quickly and becomes noticeable. Also they take even longer to start in CI/CD containers.
true, but the moment you add containers to your mix you're functionally admitting that you don't care about startup times. Or possibly, you've been forced to do it by some service provider who doesn't give you a better option...
Earlier quoted context omitted.
I agree. It has its merits, but it's hard for me to get around my visceral reaction to the fact it just bombs on filenames with spaces in them.
You can escape spaces in makefiles.
I written[1] a blog on that as well. Glad to see there are more like minded people out there.
[1] https://www.yieldcode.blog/post/why-you-should-adpot-makefil...
It's interesting, but I can't help but think that by the time you're adding `.PHONY` after most rules, you're not using the right tool for the job. (I generally find a small set of shell scripts work, or just three or four rules in the package.json file I can access with `npm run`).
I generally reach for a shell script with "case" instead, though. Can always invoke make from the shell script.
Make becomes a pretty terrible tool at a fairly low level of complexity. I would never choose it voluntarily to build things.
I tried repeatedly to just stick with Makefiles but I kept having to add workaround and hack to do basic stuff. They got uglier and uglier. I checked out go task and cargo make, but eventually gave in to `just`. It has worked just fine and the files are infinitely more readable than the comparable ones w/ make.
What kind of workarounds and hacks? Make's task interface is essentially "anything you can do at the command line", generally with the same syntax (though you have to put extra parens around your variable names). It's true that more modern tools have features make doesn't (especially with regard to manipulating complicated dependency graphs) or attack parts of the problem that make doesn't (hermetic build environment…
What I want out of task runners nowadays is to run tasks. If I can't make a task without writing '.PHONY' - there's a problem with the task runner.
It's interesting, but I can't help but think that by the time you're adding `.PHONY` after most rules, you're not using the right tool for the job. (I generally find a small set of shell scripts work, or just three or four rules in the package.json file I can access with `npm run`).
* each line executes in an isolated environment
* can't pass options or arguments to a make target
* not portable to other operating systems
the author is already using node packages. purpose-built taskrunners are plentiful, and the resulting scripts will be written in the same language as the rest of the codebase instead of adding a second language.
hiding a tool behind a makefile is my pet peeve. a proper taskrunner makes common operations easy without kneecapping the flexibility of the underlying tools.
Earlier quoted context omitted.
What kind of workarounds and hacks? Make's task interface is essentially "anything you can do at the command line", generally with the same syntax (though you have to put extra parens around your variable names). It's true that more modern tools have features make doesn't (especially with regard to manipulating complicated dependency graphs) or attack parts of the problem that make doesn't (hermetic build environment…
I see `.PHONY` as a hack, `MAKEFLAGS += --no-builtin-rules` as a workaround, and many of the builtin functions as being difficult to use, read, and understand. A long string of nested replacements generating the sources for a task is a pain to read and maintain. What I want out of task runners nowadays is to run tasks . If I can't make a task without writing '.PHONY' - there's a problem with the task runner.
It's absolutely true that ".PHONY" looks like a hack; it was sort of meant to. In general you shouldn't be using it, except maybe as a facade layer where you can put an "API" (c.f. the "all" or "clean" targets) on top of things that are themselves proper dependencies.
I'm not going to hold up make as the ultimate expression of a dependency-based build system. But I will say that history has a LONG trail of products that tried to replace it with decidedly mixed results. Categorical statements like yours tend to trigger my "code smell" layer, most of the time attempts to replace make produce worse results.
