On Fri, Apr 27, 2018 at 11:26:15PM +0200, Uwe Kleine-König wrote:
>
> I have a Makefile that works with a set of files and can run various
> checks over them. A simplified variant looks as follows:
>
> user@hostname:~/maketest$ cat Makefile
> all: check-debian check-ubuntu
>
> check-%: list-%
> @echo test for $< succeeded
>
> .PHONY: all check-debian
>
> With this Makefile (and the needed list files for debian and ubuntu:
>
> user@hostname:~/maketest$ ls
> list-debian list-ubuntu Makefile
>
> ) running make skips over check-debian's commands:
>
> user@hostname:~/maketest$ make -r
> test for list-ubuntu succeeded
>
> This matches the documentation, which has:
>
> The implicit rule search (see Implicit Rules) is skipped for
> .PHONY targets.
>
> I discussed this on irc and someone found an older GNU Make Manual
> stating:
>
> Since it knows that phony targets do not name actual files that
> could be remade from other files, make skips the implicit rule
> search for phony targets.
>
> IMHO this reasoning is wrong as in my case implicit rules for phony
> targets would be useful even though "check-debian" isn't the name of an
> actual file.
Changing the behavior of make to have it start running any random
matching implicit rule for phony targets in existing makefiles would
be ... hilarious? The existing rationales and behaviours seem sane
to me, and that isn't invalidated by an example of "my broken rules
didn't behave like I was hoping they would", especially not when the
broken example is trivial to fix with the existing behaviour of make.
The makefile you wanted to write is instead this:
CHECKS = check-debian check-ubuntu
all: $(CHECKS)
$(CHECKS): check-%: list-%
@echo test for $< succeeded
.PHONY: all $(CHECKS)
Since you are explicitly declaring the target(s) PHONY, and therefore
know exactly what they are in advance, there is no good reason to be
expecting an implicit rule to do the job that static pattern rules are
designed for and can do much more safely, without having any unintended
side-effects.
I'm not going to close this bug, since I'm neither the make maintainer
nor the submitter, but having seen the discussion on IRC (since it was
reported here) - it seems pretty obvious to me that your makefile was
just buggy and this is not a bug in make, so IMO it can be closed here.
HTH,
Ron
