View Issue Details

IDProjectCategoryView StatusLast Update
0001415Issue 8 draftsShell and Utilitiespublic2020-11-06 18:28
Reporterpsmith Assigned Toajosey  
PrioritynormalSeverityObjectionTypeClarification Requested
Status ClosedResolutionWithdrawn 
NamePaul Smith
OrganizationGNU Project
User Reference
Section(section number or name, can be interface name)
Page Number(page or range of pages)
Line Number(Line or range of lines)
Final Accepted Text
Summary0001415: The text added as a result of Issue #1325 is unacceptable
DescriptionI apologize if I'm not following the correct procedure but I'm not able to add notes to #1325 so I am opening a new issue as an objection.

The text added as a resolution to issue #1325 is not acceptable.

Regardless of the opinions of maintainers of other versions of make, the behavior of GNU make with respect to rebuilding included makefiles is every bit as legitimate a solution and there's no standardized precedent to require otherwise.

In fact, GNU make's behavior is PREFERABLE because it does not require that users define rules that rebuild makefiles before the include line is parsed in the makefile. The order of rules vs. include lines is not relevant.

GNU make is, pretty much unarguably, the single most widely used version of make existing today and its behavior in this area has been consistent and valid for 30 years or so. There's no justification for the POSIX committee to suddenly declare that such a widely-used implementation does not meet the standard.

It is not, as described by the changes proposed in #1325, "historical" and it will not be, as I have explained many, many times to Joerg, changed in the future, not even to satisfy a POSIX standard if this text is left as-is.

It is also, as I have also tried to explain many times, not an error, not misbehavior, and it does not cause failures when parallel builds are present _IF_ the makefile properly declares its prerequisite relationships. There IS a problem with rebuilding makefiles if you do NOT declare all of your prerequisite relationships, but it has nothing to do with whether included makefiles are built at the same time as the include line is parsed, and it is not even related to rebuilding makefiles: the same issue can be seen in other situations: the problem has to do with GNU make's directory cache implementation.
Desired ActionEither revert the text of #1325 or else modify it so that GNU make's behavior (delaying the rebuild of included makefiles until the entire makefile and all other included makefiles are parsed) is explicitly allowed.
TagsNo tags attached.

Relationships

child of 0001325 Closed Allow make to remake an included file 

Activities

geoffclare

2020-11-06 09:53

manager   bugnote:0005101

Now that the resolution of bug 0001325 has been updated to allow GNU make's behaviour, we need to decide what to do with this bug.

The appropriate choices would seem to be to process it as withdrawn (if Paul is okay with that), or to close it as a duplicate of 1325.

psmith

2020-11-06 14:30

developer   bugnote:0005102

Either of those is fine with me. Withdrawn might be better from a metadata point of view but it's up to you all.

Issue History

Date Modified Username Field Change
2020-10-26 16:43 psmith New Issue
2020-10-26 16:43 psmith Status New => Under Review
2020-10-26 16:43 psmith Assigned To => ajosey
2020-10-26 16:43 psmith Name => Paul Smith
2020-10-26 16:43 psmith Organization => GNU Project
2020-10-26 16:43 psmith Section => (section number or name, can be interface name)
2020-10-26 16:43 psmith Page Number => (page or range of pages)
2020-10-26 16:43 psmith Line Number => (Line or range of lines)
2020-10-26 16:54 nick Relationship added child of 0001325
2020-11-06 09:53 geoffclare Note Added: 0005101
2020-11-06 09:54 geoffclare Project 1003.1(2004)/Issue 6 => Issue 8 drafts
2020-11-06 14:30 psmith Note Added: 0005102
2020-11-06 18:28 Don Cragun Status Under Review => Closed
2020-11-06 18:28 Don Cragun Resolution Open => Withdrawn