Sorry, I did phrase that badly. A better version of that sentence would be
A single target (a single node in the dependency graph) of Make does exactly one thing: it takes input files, some dependencies and generates _exactly_one_ output file.
Excatly what I wanted to express with my post above. But the article isn't about such a case, but for something for which a single shell script (or, better, just adding the commands to the `scripts` stanza of `package.json`, which is the more common, expected way to do it) is actually better suited and way less error prone.
I'm still not really following the point about one output file? That might be Make's stated purpose, but a Makefile rule can certainly create extra files as a side effect (or do pretty much anything a shell user could do, from creating directories and downloading files to launching applications)
One of my projects has a single makefile rule which downloads and unzips a tarball, applies a patch to it, then builds the application within, resulting in half a dozen binaries which are then used in building the rest of the project.
Edit: Ah - I see what you mean now, in your subsequent comment.
Yes, but this is not particularly relevant to the user. With pattern rules it's trivial to define a large number of targets automatically, such as in the example (from the manual):
objects = foo.o bar.o
all: $(objects)
$(objects): %.o: %.c
$(CC) -c $(CFLAGS) $< -o $@The problem is a target with more than one output files, that target would look something like, which does work
foo bar: baz
compile $< -o foo -o bar
foo: baz
compile $< -o foo -o bar
bar: baz
compile $< -o foo -o bar
Scroll down to "Grouped targets". I think these address the concern you raise.
The snippet you have shown is an example of the "independent targets" pattern which the first half of that page also covers.
foo: baz
compile $< -o foo -o bar
bar: foo
A_MESS_OF_FILES := foo bar zot
MAIN_FILE := foo
SUBORDINATE_FILES := bar zot
foo: baz
sudo make me a foo
$(SUBORDINATE_FILES): %: foo
Not true. Your dependency graph might culminate on a single final target, but nothing prevents you from adding as many targets that generate as many output files as you feel like adding and set them as dependencies of your final target.
Think about it for a second. If Make was only able to output a single file, how in the world do you think it's used extensively to compile all source files of a project, generate multiple libraries, link all libraries, generate executables, and even output installers and push them to a remote repository?
> To have rules which don't generate output (like `install` or `all` or `clean` or all targets in the article) we need to resort to a hack, a special magic target like `.PHONY`
I don't understand what point you thought you were making. So a feature that boils down to syntactic sugar was added many years ago. So what? As you showed some gross misconceptions on what the tool does and how to use it, this point seems terribly odd.
> And the problem isn't that they use it, but that they are proposing it as a solution to "everybody".
I think you're making stuff up. No one wants Make to rule the world. I don't know where you got that from.
I think the whole point is that Make excels at a very specific usecase: implement workflows comprised of interdependent steps that can be resumed and incrementally updated. Being oblivious of Make leads many among us to reinvent the wheel poorly, using scripting languages to do much of the same thing but requiring far more work. If you can do this with a dozen lines of code in a Makefile, why on earth would you be churning out hundreds of lines of any random scripting language?