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'
rule.
>
> This desired behavior alone could be achieved by eliminating
ought-to-exist.
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
unrelated.
> 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
'hello'
> 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
cases.
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
<https://file.savannah.gnu.org/file/fix-48643-simpsons-v2.diff?file_id=52238>
File name: ss-trials.sh Size:2 KB
<https://file.savannah.gnu.org/file/ss-trials.sh?file_id=52239>
File name: ss-trials-out.txt Size:6 KB
<https://file.savannah.gnu.org/file/ss-trials-out.txt?file_id=52240>
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?48643>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
