[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #48643] Irrelevant targets can confuse make on which pattern rule t

From: Steven Simpson
Subject: [bug #48643] Irrelevant targets can confuse make on which pattern rule to select.
Date: Thu, 11 Nov 2021 15:43:44 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94.0

Follow-up Comment #14, bug #48643 (project make):

I've got three implementations of Make lined up.  One is master, one has my
recent changes applied to master from last month (ssfix; patch included), and
one is master with your sv48643_fix.diff applied (dgfix).  I've attached a
script to compare these on the examples you've provided (and a couple more),
and the output with these three implementations.  The comments below refer to
this output.

[comment #12 comment #12:]
> Let us say hello.c is missing, hello.f is present in the filesystem and
> consider the following example
> Example 1.
> ++++
> all: hello.tsk
> %.tsk: %.c; $(info $@ from $<)
> %.tsk: %.f; $(info $@ from $<)
> unrelated: hello.c
> ----
> The current behavior is to choose rule '%.tsk: %.c' because 'hello.c' is
> mentioned explicitly on an unrelated rule.
> The desired behavior is to skip '%.tsk: %.c' rule and choose '%.tsk: %.f'
> This desired behavior alone could be achieved by eliminating
For this example, all three Makes fail when no source is provided, but
make-dgfix and master report no rule for 'hello.c', while make-ssfix reports
no rule for 'hello.tsk'.  When 'hello.f' is present but 'hello.c' is not,
master finds no rule for 'hello.c', while make-dgfix and make-ssfix correctly
build from 'hello.f'.  In the other two circumstances, they are identical.

For further comparison, I also dropped the 'unrelated' line, and all three
implementations produce the same results in all circumstances.  Note that
make-ssfix generates the same error in the no-source case, regardless of the
presence or absence of the 'unrelated' line, so it is treating it as

> However, let us consider the following example which demonstrates that
> ought-to-exist concept has to stay.
To be clear, I agree that ought-to-exist has to stay, but the documented and
implemented definitions are too broad, as you say.

> i think, a good change is to restrict ought-to-exist as this
> ++++
> "If a file name is mentioned in the makefile as a target or as an explicit
> prerequisite of the current target, then we say it ought to exist."
> ----
Sounds good.

> Example 2.
> ++++
> all: hello.tsk
> hello.tsk: hello.c
> %.tsk: %.c; $(info $@ from $<)
> %.tsk: %.f; $(info $@ from $<)
> ----
For this one, all three Makes are identical in all circumstances, so
make-ssfix _has not got rid of_ this part of the ought-to-exist definition.

> Example 3.
> ++++
> all: hello.tsk
> %.tsk: %; $(info $@ from $<)
> unrelated: hello
> ----
(Aside: Is the lack of a suffix significant?)

> In this example rule '%.tsk: %' is chosen to build hello.tsk, because
> is mentioned explicitly on an unrelated rule.
Are you saying that this also should be the correct behaviour?

With no 'hello' file, master and make-dgfix complain of no rule for 'hello',
while make-ssfix complains for 'hello.tsk'.  All three Makes behave
identically when 'hello' exists.

With the 'unrelated' line removed, all three Makes are identical in both

As with Example 1, make-ssfix's behaviour is consistent whether the
'unrelated' line is present or not, especially in the case where source is
absent, i.e., the error message is the same.

There's only a difference between the implementations when the Makefile isn't
going to work anyway, i.e., when 'hello' doesn't exist.  If there's a way to
build 'hello' too, it must appear as a target, so I don't think Example 3
demonstrates a case where the broader behaviour is required.

(file #52238, file #52239, file #52240)

Additional Item Attachment:

File name: fix-48643-simpsons-v2.diff     Size:1 KB

File name: ss-trials.sh                   Size:2 KB

File name: ss-trials-out.txt              Size:6 KB


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]