[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

[Dmitry Goncharov]

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

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.

However, let us consider the following example which demonstrates that
ought-to-exist concept has to stay.

Example 2.
++++
all: hello.tsk
hello.tsk: hello.c
%.tsk: %.c; $(info $@ from $<)
%.tsk: %.f; $(info $@ from $<)
----

When make considers rule '%.tsk: %.c' make discovers that hello.c is an
explicit prerequisite of the current target hello.tsk.  This qualifies hello.c
as ought to exist and tells make to choose this rule.  Regardless of whether
hello.c is present in the filesystem.  Even if hello.c is missing and hello.f
is present make still has to choose '%.tsk: %.c' rule, rather then '%.tsk:
%.f' rule, because the user specified hello.c as an explicit prerequisite of
hello.tsk.


On the other hand, when hello.c is an explicit prerequisite of an unrelated
rule (as in example 1), then the current definition of ought-to-exist is too
broad and causes an unrelated rule to be chosen.

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

This will exclude unrelated rules in example 1, but still allow the intended
use case of ought-to-exist presented above in example 2.

However, this change of the definition of ought-to-exist and the related
change in the implementation will break the makefiles that depend on the old
behavior.

Example 3.
++++
all: hello.tsk
%.tsk: %; $(info $@ from $<)
unrelated: hello
----

In this example rule '%.tsk: %' is chosen to build hello.tsk, because 'hello'
is mentioned explicitly on an unrelated rule.

We need to solve both
1. Skip unrelated rules.
and
2. Be compatible with makefiles that depend on unrelated rules.

The simplest and most reliable solution that meets both of these goals, i have
found is the following
++++
1. Change the definition of ought-to-exist as described above.
2. Search according to the new definition of ought-to-exist. This will skip
all unrelated rules and achieve the desired effect.
3. If no rule is found, then search according to the old definition of
ought-to-exist. This allows makefiles which depend on the old definition of
ought-to-exist to keep working.
----
Notes about this proposed solution
1. This solution does not attempt to build the prerequisite in order to decide
if it can be used. I explored possible solutions which build the prerequisite
and came to the conclusion, the right behavior is to not attempt to build
one.

2. Compatibility search (step 3 in the algorithm above) should only be
performed, if the initial search finds such a prerequisite that is explicitly
mentioned on an unrelated rule. This ensures that if the makefile does not
have such a prerequisite, then no compatibility search is performed.

3. We could introduce a warning when compatibility search is performed and
advice the user to fix the makefile.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?48643>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/