bugmake - Bugs: bug #60399, Incorrect dependencies with...

 
 

bug #60399: Incorrect dependencies with grouped targets

Submitter:  Sean Anderson <callous_stream>
Submitted:  Thu 15 Apr 2021 06:17:55 PM UTC
   
 
Severity:  3 - Normal Item Group:  Enhancement
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Component Version:  4.3 Operating System:  POSIX-Based
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 07 Sep 2021 03:04:37 AM UTC, comment #3: 

There is this difference in behavior between the 2 makefiles.
In the cause of

.PHONY: b
a b&:; touch a b

b is phony and a is not phony.

In the case of

.PHONY: force
b: force
a b&:; touch a b

Both a and b depend on force.

Do you think make should behave the same in both cases?

Dmitry Goncharov <dgoncharov>
Tue 07 Sep 2021 12:56:52 AM UTC, comment #2: 

Re-reading this I think I want to retract my earlier comment that this does not seem right.  I think that make's behavior here is correct.

But, I'm willing to be convinced otherwise if there are good arguments for it.

The way a grouped target works is that a single invocation of the recipe builds ALL targets.  This implies that if any single target in the set of grouped targets is out of date, then all the targets will be built.  In this example b is always out of date, and so the targets will always be built.

Just to check I tried using a pattern rule with multiple targets in this same way (forcing only one of the targets to be out of date then explicitly building the other one) and it worked the same way: both targets were rebuilt rather than saying "up to date".

I'll leave this open as an enhancement to consider, and will be interested to hear others' thoughts, but at this point I think the current behavior of GNU make is correct and no changes are needed.

Paul D. Smith <psmith>
Group administrator
Sat 17 Apr 2021 08:50:04 PM UTC, comment #1: 

I agree that this behavior does not seem right.

First, the output of --trace is misleading.  Using -d is slightly more understandable.

I think that the way it's implemented is that a prerequisite of any element of a group is considered to be a prerequisite of the entire group.  So by saying that b depends on FORCE, that also implies that a depends on FORCE: they are considered a group and can't really be managed separately.  It wasn't really considered that the out-of-date computation of one element of the group might make a different decision on whether to rebuild, if only that one element was considered.

Oddly, it appears that .PHONY (and, probably other special targets like it) apply to individual members of the group rather than the entire group like regular prerequisites.

Paul D. Smith <psmith>
Group administrator
Thu 15 Apr 2021 06:17:55 PM UTC, original submission:  

The following makefile demonstrates some unexpected (buggy?) behavior


.PHONY: FORCE
b: FORCE
a b&:
        touch a
        touch b


What I expected to happen was

  • Running "make a" for the first time would run the recipe.
  • Running "make a" when "a" already existed would do nothing.
  • Running "make b" would always run the recipe.


Instead, I observe the following behavior:


$ make --trace a
Makefile:4: target 'a' does not exist
touch a
touch b
$ make --trace b
Makefile:4: update target 'b' due to: FORCE
touch a
touch b
$ make --trace a
Makefile:4: target 'a' does not exist
touch a
touch b


In this example, "FORCE" is used to represent some dependency of "b" which has been updated since the last run of "make". However, this behavior is also present if "FORCE" is replaced by some regular file which is updated between "make" runs.

If the makefile is modified slightly to


.PHONY: b
a b&:
        touch a
        touch b


Then I observe the following behavior:


$ make --trace a
Makefile:3: target 'a' does not exist
touch a
touch b
$ make --trace b
Makefile:3: target 'b' does not exist
touch a
touch b
$ make --trace a
make: 'a' is up to date.


From this, it seems that "a" is incorrectly marked as ".PHONY" in the first example. I'm not sure whether this is intended (albeit strange) behavior, or a bug.

Sean Anderson <callous_stream>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dgoncharov (Posted a comment)
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by callous_stream (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-09-07 psmith Item GroupBug Enhancement

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code