[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: Paul D. Smith
Subject: [bug #48643] Irrelevant targets can confuse make on which pattern rule to select.
Date: Sun, 23 Jan 2022 20:51:46 -0500 (EST)

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

I played for a while this weekend with adding a warning for compatibility
mode, but I'm not sure we can really do it.  There are two problems which may
be related.

The first one is that the output appears even if make ultimately decides that
there is no way to build the target.  For example, the last test in
features/double_colon fails: it uses this makefile:

all: hello.z
%.z:: %.x; touch $@
%.x: ;
unrelated: hello.x

The expected output is:

make: *** No rule to make target 'hello.x', needed by 'hello.z'.  Stop.

When I put my extra warning in I get this output:

make: Detected a compatibility rule to build 'hello.z'.
make: Using compatibility rule '%.z:: %.x' due to unrelated 'hello.x'.
make: *** No rule to make target 'hello.x', needed by 'hello.z'.  Stop.

It seems odd to warn about finding compatibility rules if we then end up not
being able to build anyway, but there's no way to know, when we detect the
compatibility rule, whether we will succeed or not.  But, maybe this isn't a
problem since it may be that the warnings help us understand why make decided
to follow that path and get that error.

However, the larger problem can be seen with this exact same example: as you
mentioned in comment #33 the above makefile form is actually a very common way
to prevent make from treating a prerequisite as an intermediate file
(mentioning it in a different rule).  Although I didn't find too many
instances of this in my tests I know they are actually quite common and this
makes me concerned that adding this warning will cause lots of warnings in
real makefiles.  It also may well mean that we won't ever be able to remove
the compatibility search at all, because without this we don't get the above
error at all: instead we just get a successful "Nothing to be done for

Of course, the user could add an explicit *hello.z: hello.x* to fix this
problem.  But, I'm not sure we can add this requirement.

Anyway that is something to consider for the future.


Reply to this item at:


  Message sent via Savannah

reply via email to

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