[ajross]

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 environments, language-aware features like package management).

But... I can't see "lack of ability to do basic stuff" as one of its problems. What basic things are you trying to do?

[jsoverson]

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.

[ajross]

Meh. OK. Though almost always, "run tasks" implies some level of state. Are you tasks truly all idempotent and parallelizable? If not, maybe they should produce output and be tracked by dependencies? If so, then you probably have bugs in your "task runners" that will show up in weird ways.

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.

[throw10920]

> Though almost always, "run tasks" implies some level of state.

Yes! But isn't one of the major design principles of Make that the host filesystem is the container for the state? (iirc Make decides when to re-run rules based on when the timestamp on a target is older than the timestamp on an input file)

[ajross]

Sure, so where does that state get stored in a pure "task runner" tool? Attempts to muck with this metaphor ("state is what is left behind when the tool is not running") are among the worst mistakes made by build systems. It's a feature, not a bug, and everyone who believes otherwise ends up rediscovering it the hard way.

[klodolph]

GNU Make only recently added any support for rules which produce multiple targets.