View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001415 | Issue 8 drafts | Shell and Utilities | public | 2020-10-26 16:43 | 2020-11-06 18:28 |
Reporter | psmith | Assigned To | ajosey | ||
Priority | normal | Severity | Objection | Type | Clarification Requested |
Status | Closed | Resolution | Withdrawn | ||
Name | Paul Smith | ||||
Organization | GNU 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 | |||||
Summary | 0001415: The text added as a result of Issue #1325 is unacceptable | ||||
Description | I 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 Action | Either 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. | ||||
Tags | No tags attached. |
child of | 0001325 | Closed | Allow make to remake an included file |
|
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. |
|
Either of those is fine with me. Withdrawn might be better from a metadata point of view but it's up to you all. |
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 |