Follow-up Comment #1, bug #66073 (group make): A user reported an issue here https://lists.gnu.org/archive/html/help-make/2024-08/msg00001.html.
Here is a copy of that email which contains a good description of the issue.
Hi.
I have two similar Makefiles.
[Makefile1]
.PHONY: all
all: foo.p foo.q
foo.p foo.q &: foo.r FORCE
@echo \$$? = $?
touch foo.p ; touch foo.q
.PHONY: FORCE
[Makefile2]
.PHONY: all
all: foo.p foo.q
%.p %.q : %.r FORCE
@echo \$$? = $?
touch foo.p ; touch foo.q
.PHONY: FORCE
The two Makefiles are the same, except for one line.
Makefile1 uses grouped targets.
Makefile2 uses a pattern rule with multiple targets.
My hope is that those two work in the same way.
[test Makefile1]
$ rm -f foo.*
$ touch foo.r
$ touch foo.p
$ make -f Makefile1
$? = foo.r FORCE
touch foo.p ; touch foo.q
[test Makefile2]
$ rm -f foo.*
$ touch foo.r
$ touch foo.p
$ make -f Makefile2
$? = FORCE
touch foo.p ; touch foo.q
The value of $? is different.
I just thought this was fixed by
commit fabb03eac412b5ea19f1a97be31dc8c6fa7fc047
In my opinion, the behavior of Makefile1 is preferred.
Is the behavior of Makefile2 expected?
i think, foo.r should not be in $? in this case.
make first considers foo.p. Make finds out that foo.p needs to be rebuilt due
to FORCE. The recipe builds both foo.p and foo.q. Automatic variables are set
per recipe execution. When this recipe runs, $? is set to FORCE, because FORCE
is the prerequisite that caused the recipe to run.
foo.q is not even considered at all at this point.
Then make considers foo.q and finds out that foo.q is already built. Make runs
no recipe specifically for foo.q and so no automatic variables are set for
foo.q.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66073>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
