Joerg Schilling <[email protected]> wrote, on 05 Nov 2020: > > Geoff Clare via austin-group-l at The Open Group > <[email protected]> wrote: > > > The <i>make</i> utility shall use one of the following two methods > > to attempt to create the file or bring it up-to-date: > > > > 1. The "immediate remaking" method > > > > If <i>make</i> uses this method, any target rules or inference > > rules for the pathname that were parsed before the include line > > was parsed shall be used to attempt to create the file or to > > bring it up-to-date before opening the file. > > > > 2. The "delayed remaking" method > > > > If <i>make</i> uses this method, no attempt shall be made to > > create the file or bring it up-to-date until after the > > makefile(s) have been read. During processing of the include > > line, <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. > > Once the makefile(s) have been read, <i>make</i> 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, [...] > > > > If the pathname is relative, [...] > > Sorry, but this would result in non-portable makefiles and it is not > acceptable. > > In order to permit portable makefiles, all rules to make/remake include files > need to be before the include statement.
That's a constraint on applications, not on impelementations. It is covered by the first bullet point in the proposed APPLICATION USAGE addition. -- Geoff Clare <[email protected]> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
