A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1325 ====================================================================== Reported By: dmitry_goncharov Assigned To: ====================================================================== Project: Issue 8 drafts Issue ID: 1325 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Under Review Name: Dmitry Goncharov Organization: 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: https://austingroupbugs.net/view.php?id=1325#c5066 ====================================================================== Date Submitted: 2020-02-09 17:17 UTC Last Modified: 2020-11-03 15:23 UTC ====================================================================== Summary: Allow make to remake an included file ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- parent of 0001415 The text added as a result of Issue #13... ======================================================================
---------------------------------------------------------------------- (0005094) psmith (developer) - 2020-11-03 15:23 https://austingroupbugs.net/view.php?id=1325#c5094 ---------------------------------------------------------------------- Thank you for all your effort Geoff! I like this version very much. A few notes / clarifying questions: Regarding the change to page 2891 lines 97033-97035: is this because smake / SunPro make will re-consider and re-build included makefiles if they appear as prerequisites to another target? GNU make never reconsiders a target after it's been considered, regardless of whether or not it's an included file. Regarding this: > If a target rule or inference rule for the pathname has been parsed before the include line is parsed, make shall use the rule to attempt to create the file or to bring it up-to-date. I don't think this is quite correct. In GNU make, anyway, it's not required that an inference rule parsed before the include line is parsed will always be used. If a target rule, or a different inference rule, is defined after the include line then that will be used instead. For the section "Additionally in this case, the new contents of the file, if it is successfully created or updated, shall be used when processing rules for the following targets after the makefile(s) have been read:" followed by the bullet points, can you give me a hint as to what we are trying to ensure or prevent by this text? By listing these specific things I worry that I will overlook something that we do today that will become invalid as a result of this text. Is there a difference we are trying to surface between how included files normally work, and these rebuilt included files work? Is it not sufficient to say something like, the new contents of the file will be used when processing rules that appear after the included file as if the text had appeared in the makefile? In the portability text (second bullet), a portable workaround to using a macro defined in one included file in the include line of another, is to put the second include _inside_ the first included file instead of in the outer including makefile. This can be less convenient in some situations but it will work in all situations. In the portability text I don't understand the need for the third bullet...? In the make examples text I am not sure what the point of the initial -include line is... why is that needed in this situation? It also seems that each target will list all its prerequisites twice, although of course that's not a problem. You might also consider using the make variable $(CC) in these examples rather than hardcoding the c99 value. Regarding the issue of searching of include files, I don't agree with this as written. I do understand the problem you're addressing, and I have no problems making some types of changes to GNU make to meet the standard, but the loss of functionality here is too great. Consider an environment where users want to place their included files in a separate directory "ddir" then use "include $(CFILES:.c=.d)" and adds "ddir" to the include file search path. This won't work as expected with this wording. One way to square this circle may be to provide a bit more context around included search paths; we may need to make a distinction between "user specified search paths" and "default" or "system" search paths. I'm OK with saying that "default" search paths, if the implementation contains any, are only searched for makefiles if the makefile cannot be remade and even that these are not eligible to be rebuilt. But, I think that user-defined search paths shouldn't preclude those makefiles from being rebuilt. Regarding the make rationale text specifying potential issues to consider with "delayed remaking", I'm not sure that such advice to implementors really belongs in the spec, even in the rationale section, but I have no problems with it if you want to keep it here. But, perhaps instead of saying "a number of ''gotchas''" perhaps just something like "keep these potential QOI issues in mind" :). Issue History Date Modified Username Field Change ====================================================================== 2020-02-09 17:17 dmitry_goncharovNew Issue 2020-02-09 17:17 dmitry_goncharovName => Dmitry Goncharov 2020-02-09 17:17 dmitry_goncharovSection => (section number or name, can be interface name) 2020-02-09 18:29 shware_systems Note Added: 0004780 2020-02-10 13:27 joerg Note Added: 0004781 2020-02-10 13:28 joerg Note Edited: 0004781 2020-10-26 15:52 geoffclare Project Online Pubs => Issue 8 drafts 2020-10-26 15:53 geoffclare Note Added: 0005066 2020-10-26 15:54 geoffclare Page Number => (page or range of pages) 2020-10-26 15:54 geoffclare Line Number => (Line or range of lines) 2020-10-26 15:54 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1325#c5066 2020-10-26 15:54 geoffclare Status New => Resolved 2020-10-26 15:54 geoffclare Resolution Open => Accepted As Marked 2020-10-26 15:54 geoffclare version => Draft 1 2020-10-26 15:54 geoffclare Tag Attached: issue8 2020-10-26 16:54 nick Relationship added parent of 0001415 2020-10-26 16:57 rhansen Note Added: 0005068 2020-10-26 16:58 rhansen Note Edited: 0005068 2020-10-26 17:00 rhansen Note Edited: 0005068 2020-10-26 17:08 nick Note Added: 0005069 2020-10-26 17:08 nick Resolution Accepted As Marked => Reopened 2020-10-26 22:34 nick Status Resolved => Under Review 2020-10-27 10:09 geoffclare Note Added: 0005070 2020-10-27 13:09 joerg Note Added: 0005071 2020-10-27 13:10 joerg Note Edited: 0005071 2020-10-27 14:04 psmith Note Added: 0005072 2020-10-27 14:36 psmith Note Added: 0005073 2020-10-27 15:24 joerg Note Added: 0005074 2020-10-27 15:26 joerg Note Edited: 0005074 2020-10-27 18:28 psmith Note Added: 0005075 2020-10-27 18:30 psmith Note Added: 0005076 2020-10-28 09:14 geoffclare Note Added: 0005077 2020-10-28 11:23 joerg Note Added: 0005078 2020-10-28 12:16 joerg Note Edited: 0005078 2020-10-28 13:47 psmith Note Added: 0005079 2020-10-28 14:44 geoffclare Note Added: 0005080 2020-10-28 14:49 psmith Note Added: 0005081 2020-10-28 14:50 psmith Note Added: 0005082 2020-10-28 14:53 psmith Note Added: 0005083 2020-10-28 15:08 shware_systems Note Added: 0005084 2020-10-30 15:56 geoffclare Note Added: 0005087 2020-10-30 16:10 geoffclare Note Edited: 0005087 2020-10-30 16:14 geoffclare Note Edited: 0005087 2020-10-30 18:52 joerg Note Added: 0005089 2020-10-30 18:52 joerg Note Edited: 0005089 2020-10-30 18:53 joerg Note Edited: 0005089 2020-10-30 18:54 joerg Note Edited: 0005089 2020-10-30 18:56 joerg Note Edited: 0005089 2020-10-30 19:33 joerg Note Edited: 0005089 2020-10-31 09:13 geoffclare Note Edited: 0005087 2020-10-31 09:16 geoffclare Note Edited: 0005087 2020-10-31 09:21 geoffclare Note Added: 0005090 2020-10-31 09:38 geoffclare Note Edited: 0005087 2020-10-31 09:47 geoffclare Note Edited: 0005087 2020-10-31 09:47 geoffclare Note Edited: 0005087 2020-11-03 15:23 psmith Note Added: 0005094 ======================================================================
