4 ms·

> Make does exactly one thing: it takes input files, some dependencies and generates _exactly_one_ output file. Not true. Your dependency graph might culminate

> Make does exactly one thing: it takes input files, some dependencies and generates _exactly_one_ output file. 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?

ReleaseCandidat 2y ago
> 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. 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. > 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.
- chongli 2y ago
  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. 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 $@
  - ReleaseCandidat 2y ago
    I have been unclear in my formulation, sorry. 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.
    - robinsonb5 2y ago
      So can that be solved like this, or is there some other subtlety I'm missing? 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!)
      - oneeyedpigeon 2y ago
        > Text after a blank line that is indented by two or more spaces is reproduced verbatim. (This is intended for code.) (from https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc)
      - mauvehaus 2y ago
        Among other things, now you have to maintain a set of dummy targets. If you have a variable (possibly generated) that is basically 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

ReleaseCandidat 2y ago

> 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. 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. > 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.

chongli 2y ago
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. 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 $@
- ReleaseCandidat 2y ago
  I have been unclear in my formulation, sorry. 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.
  - robinsonb5 2y ago
    So can that be solved like this, or is there some other subtlety I'm missing? 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!)
    - oneeyedpigeon 2y ago
      > Text after a blank line that is indented by two or more spaces is reproduced verbatim. (This is intended for code.) (from https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc)
    - mauvehaus 2y ago
      Among other things, now you have to maintain a set of dummy targets. If you have a variable (possibly generated) that is basically 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