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
but as this is the same as writing foo: baz
compile $< -o foo -o bar
bar: baz
compile $< -o foo -o bar
to generate `foo` and `bar` the rule is run twice in a parallel build (`make -j 2`. Which may just be unnecessary or it may break the whole build.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
(Can someone tell me how to do code tags on HN please? :) Edit: fixed now, thanks!) A_MESS_OF_FILES := foo bar zot
You now have to create dummy targets for bar, baz, and zot and not forget to add them. Or maybe break it into MAIN_FILE := foo
SUBORDINATE_FILES := bar zot
foo: baz
sudo make me a foo
$(SUBORDINATE_FILES): %: foo
Sorry, I did phrase that badly. A better version of that sentence would be
> I think the whole point is that Make excels at a very specific usecase [..]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.