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-10-30 15:56 UTC ====================================================================== Summary: Allow make to remake an included file ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- parent of 0001415 The text added as a result of Issue #13... ======================================================================
---------------------------------------------------------------------- (0005087) geoffclare (manager) - 2020-10-30 15:56 https://austingroupbugs.net/view.php?id=1325#c5087 ---------------------------------------------------------------------- Here is an alternative proposal that is intended to allow GNU make's delayed remaking of include files. It also fixes some things we missed in the original resolution:<blockquote>The wording change was made in text whose context is a relative pathname. It needs to be separated from that context so that it also applies to absolute pathnames. The -n option is ignored when the command lines in a rule are being processed in order to create or update an include file. GNU make also does the same for -q and -t, but SunPro make doesn't.</blockquote> I have also proposed a change to c99 -E to ensure it is usable for generating dependencies. The change is the minimum needed for this purpose - a more detailed change could be made instead if desired. Alternatively we could add a -M option. Page and line numbers are for Issue 8 draft 1. On page 2888 line 96923 (make -n option), change:<blockquote>However, lines with a <plus-sign> ('+') prefix shall be executed.</blockquote>to:<blockquote>However, lines with a <plus-sign> ('+') prefix and lines being processed in order to create an include file or to bring it up-to-date (see <b>Include Lines</b> in the EXTENDED DESCRIPTION section) shall be executed.</blockquote> On page 2889 lines 96929-96931 (make -q option), after:<blockquote>However, a makefile command line (associated with the targets) with a <plus-sign> ('+') prefix shall be executed</blockquote>add:<blockquote>and it is unspecified whether command lines that do not have a <plus-sign> prefix and are being processed in order to create an include file or to bring it up-to-date (see <b>Include Lines</b> in the EXTENDED DESCRIPTION section) are executed</blockquote> On page 2889 lines 96943-96944 (make -t option), after:<blockquote>However, a command line with a <plus-sign> ('+') prefix shall be executed.</blockquote>add:<blockquote>and it is unspecified whether command lines that do not have a <plus-sign> prefix and are being processed in order to create an include file or to bring it up-to-date (see <b>Include Lines</b> in the EXTENDED DESCRIPTION section) are executed</blockquote> On page 2891 lines 97033-97035 (make extended description), after:<blockquote>A target shall be considered up-to-date if it exists and is newer than all of its dependencies, or if it has already been made up-to-date by the current invocation of <i>make</i> (regardless of the target's existence or age)</blockquote>add:<blockquote>, except that targets that are made up-to-date in order for them to be processed as include line pathnames (see <b>Include Lines</b> below) need not be considered up-to-date during later processing</blockquote> On page 2892 lines 97097-97102 (make extended description), change:<blockquote><ul><li>Each pathname that does not begin with a '/' shall be treated as relative to the current working directory of the process, not relative to the directory containing the makefile. If the file does not exist in this location, it is unspecified whether additional directories are searched. If the file cannot be opened, and if the word <b>include</b> was prefixed with a <hyphen-minus> character, the file shall be ignored. Otherwise, if the file cannot be opened an error shall occur.</li></ul></blockquote>to:<blockquote><ul><li>If the pathname does not begin with a '/', it shall be treated as relative to the current working directory of the process, not relative to the directory containing the makefile.</li> <li>If a target rule or inference rule for the pathname has been parsed before the include line is parsed, <i>make</i> shall use the rule to attempt to create the file or to bring it up-to-date. However, it is unspecified whether this action is performed before opening the file or after the makefile(s) have been read. If it is performed after the makefile(s) have been read, <i>make</i> shall read the current contents of the file, if it exists, or treat it as an empty file if it does not exist, during processing of the include line and shall use any applicable target rule or inference rule for the pathname, regardless of whether it is parsed before or after the include line, when creating the file or bringing it up-to-date. 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: <ul> <li>The <i>target_name</i> operands, if any.</li> <li>The first target <i>make</i> encounters that is not a special target or an inference rule, if no <i>target_name</i> operands are specified.</li> <li>All targets that are prerequisites, directly or recursively, of the above targets.</li></ul> If the pathname is relative, the file does not exist, and an attempt to create it using a rule has not been made and will not be made, it is unspecified whether additional directories are searched for an existing file of the same relative pathname. If, after proceeding as described above, the file still cannot be opened:<ul><li>If the word <b>include</b> was prefixed with a <hyphen-minus> character, the file shall be ignored.</li> <li>Otherwise, an error shall occur.</li></ul></ul></blockquote> On page 2904 after line 97617 (make application usage), insert the following new paragraphs:<blockquote>The requirements for creating and updating include files allow two different methods, as explained in RATIONALE below. In order to write a set of makefiles and include files that work with both methods, applications need to ensure the following:<blockquote><ul><li>Rules containing commands for creating include files (and any prerequisites) precede the include line that will cause the file to be read.</li> <li>Rules for creating include files do not depend on the contents of any earlier include file. For example, defining a macro in an include file and using that macro in a later include line should be avoided.</li> <li>One of the rules used in creating an include file, or a prerequisite of an include file, contains commands to create its target and does not ignore creation failure.</li></ul></blockquote></blockquote> On page 2905 after line 97644 (make examples), insert a new example 4 and renumber the later examples:<blockquote>The following is an extended version of the previous example that generates <i>make</i> include files containing the prerequisites for each object file. The include file also contains its own prerequisites, and the makefile arranges that these are used by including the file twice. The first time <i>make</i> is run, the file does not exist but the use of the <hyphen-minus> prefix on the first include line means it is ignored and is then generated by the rule preceding the second include line. On subsequent runs, if any of the source or header files previously identified has changed, the include file will be updated. There are other ways of updating the include file when headers change, but they involve recursive execution of <i>make</i>.<pre>.POSIX: .SUFFIXES: .c .d OFILES = a.o b.o pgm: $(OFILES) c99 $(OFILES) -o pgm a.o: c99 -c a.c b.o: c99 -c b.c -include $(OFILES:.o=.d) .c.d: +{ \ set -o pipefail; cfile=$<; ofile=$${cfile%.c}.o; \ printf '%s %s: %s ' "$$ofile" $@ $<; \ c99 -E $< | LC_ALL=C sed -n \ '/^#[[:blank:]]*[[:digit:]]/s/.*"\([^"]*\.h\)".*/\1/p' | \ LC_ALL=C sort -u | tr '\n' ' '; \ echo; \ } > $@ include $(OFILES:.o=.d)</pre> This example does not cope with a header file being removed (<i>make</i> will complain that it does not know how to make it), necessitating that <b>*.d</b> be removed and the <i>make</i> run again. Alternatively, this can be handled by updating the commands which generate the <b>.d</b> file so that they add an empty target rule for each of its prerequisites.</blockquote> On page 2911 after line 97926 (make rationale), insert the following new paragraphs:<blockquote>This standard allows two different methods of creating include files or bringing them up-to-date, reflecting established practice in SunPro <i>make</i> and GNU <i>make</i>. The former performs this action during parsing, before the include file is opened. The latter delays performing the action until after all makefiles have been read. Implementors who opt for the ``delayed remaking'' method should be aware that it has a number of ``gotchas'':<ul><li>Diagnostic messages about missing include files must be deferred until the final exit status is known.</li> <li>If the way <i>make</i> handles using updated include file contents is to start over after include files have been made up-to-date, it is possible for a poorly written makefile to cause <i>make</i> to enter a sequence of restarts where nothing changes each time, resulting in the sequence continuing indefinitely unless the situation is detected. Implementors are encouraged to include a mechanism for detecting and reporting this, rather than allowing <i>make</i> to consume an arbitrary amount of system resource until it is forcibly terminated.</li> <li>If <i>make</i> uses this start-over method, makefile contents read from a pipe on standard input or from a FIFO must be copied to a temporary file, and when <i>make</i> starts over it must use this file instead.</li> <li>If <i>make</i> starts over by executing itself using the <i>exec</i> family of functions, the need to replace '-' or the pathnames of FIFOs with the pathnames of temporary files can lead to the <i>exec</i> call failing with an [E2BIG] error if the original execution was close to the {ARG_MAX} limit. Although this is a quality of implementation issue, not a conformance issue (since the general rules for utility errors allow utilities to fail when they encounter a variety of internal errors - see [xref to 1.4 Utility Description Defaults]), implementors are encouraged to explore ways to prevent it, such as passing information via a temporary file instead of on the command line when an [E2BIG] error has occurred. Another solution might be to jump (e.g. using <i>siglongjmp</i>()) back to the start of <i>main</i>() as the way to start over. Making a recursive call to <i>main</i>() is not recommended, as that would run into the stack limit if sufficiently many restarts are needed.</li></ul> This standard specifies that a non-existent include file is first created if possible, and only if not possible can other directories be searched. Historical versions of GNU <i>make</i> first searched the include directories, then attempted to create the include file. This behavior was not considered suitable for standardization as it means writers of portable applications have to use absolute pathnames for all include files that need to be created via a rule (because they can never be sure what relative pathnames are safe to use, since a file with the same relative pathname might happen to exist in one of the searched directories when installing the application on a new system).</blockquote> On page 2456 line 80506-80508 (c99 STDOUT), after:<blockquote>If the <b>-E</b> option is specified, the standard output shall be a text file that represents the results of the preprocessing stage of the language; it may contain extra information appropriate for subsequent compilation passes</blockquote>add:<blockquote>and shall contain at least one line with the format:<pre>"# %d \"%s\"\n", <line>, <pathname></pre>for each file processed as a result of a <b>#include</b> directive, unless no other output generated from that file is present in the output, where <tt><<i>line</i>></tt> is a line number and <tt><<i>pathname</i>></tt> is the pathname used to open the file</blockquote> On page 2463 after line 80819 (c99 rationale), add a new paragraph:<blockquote>This standard requires that, when <b>-E</b> is used, lines beginning with '#' are output identifying the files processed as a result of <b>#include</b> directives in order that <i>c99</i> <b>-E</b> can be used to generate makefile dependencies. See [xref to make]. Usually such lines are output each time the origin of the subsequent lines in the output changes, and the line number after the '#' is the line number in the named file of the line from which the next line in the output was derived.</blockquote> 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 ======================================================================
