Minutes of the 5th November 2020 Teleconference
All
Enclosed are the minutes of the thursday call this week
regards
Andrew
--
Minutes of the 5th November 2020 Teleconference Austin-1078 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 7th November 2020
Attendees:
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Don Cragun, IEEE PASC OR
Geoff Clare, The Open Group
Richard Hansen
Eric Blake, Red Hat, The Open Group OR
Joerg Schilling, FOKUS Fraunhofer
Andrew Josey, The Open Group (late)
Paul Smith
Apologies:
Tom Thompson, IEEE
Eric Ackermann, HPI, University of Potsdam
* General news
Andrew noted that the New APIs draft has been prepared and circulated
for informal comments to The Open Group Base Working Group.
* Outstanding actions
(Please note that this section has been flushed to shorten the minutes -
to locate the previous set of outstanding actions, look to the minutes
from 13th June 2019 and earlier)
Bug 1254: "asynchronous list" description uses "command" instead of "AND-OR
list" OPEN
https://austingroupbugs.net/view.php?id=1254
Action: Joerg to investigate how his shell behaves.
Bug 700 - Nick to raise this issue with the C committee
Bug 713 - Nick to raise with the C committee.
Bug 739 - Nick to raise with the C committee.
* Current Business
Bug 1325: Allow make to remake an included file Accepted as Marked
https://austingroupbugs.net/view.php?id=1325
This item is tagged for Issue 8.
Page and line numbers are for Issue 8 draft 1.
On page 2888 line 96923 (make -n option), change:
However, lines with a ('+') prefix shall be executed.
to:
However, lines with a ('+') prefix and lines being
processed in order to create an include file or to bring it
up-to-date (see Include Lines in the EXTENDED DESCRIPTION
section) shall be executed.
On page 2889 lines 96929-96931 (make -q option), after:
However, a makefile command line (associated with the targets)
with a ('+') prefix shall be executed
add:
and it is unspecified whether command lines that do not have a
prefix and are being processed in order to create
an include file or to bring it up-to-date (see Include Lines
in the EXTENDED DESCRIPTION section) are executed
On page 2889 lines 96943-96944 (make -t option), after:
However, a command line with a ('+') prefix shall be executed.
add:
and it is unspecified whether command lines that do not have a
prefix and are being processed in order to create
an include file or to bring it up-to-date (see Include Lines
in the EXTENDED DESCRIPTION section) are executed
On page 2891 lines 97033-97035 (make extended description), after:
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 make (regardless
of the target's existence or age)
add:
, except that targets that are made up-to-date in order for
them to be processed as include line pathnames (see Include
Lines below) need not be considered up-to-date during later
processing
On page 2892 lines 97097-97102 (make extended description), change:
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 include was prefixed with
a character, the file shall be ignored.
Otherwise, if the file cannot be opened an error shall
occur.
to:
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.
The make utility shall use one of the following two methods
to attempt to create the file or bring it up-to-date:
The ``immediate remaking'' method
If make 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.
The ``delayed remaking'' method
If make 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, make 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, make shall use any applicable target rule or
inference rule for the pathname, regardless of whether
it is parsed bef
make pattern rules (was: Re: [Issue 8 drafts 0001325]: Allow make to remake an included file)
Unless we are proposing pattern rules for inclusion in POSIX, which I personally would be in favor of since they are much more useful than suffix rules, perhaps we should move the discussion to a different list? On Fri, 2020-11-06 at 13:25 +0100, Joerg Schilling wrote: > > I'm not sure where the idea that pattern rules are immutable comes > > from: in GNU make any pattern rule can be overwritten at any time, > > including the default pattern rules. > > This is how pattern rules have been defined when they appeared in > SunPro Make in January 1986. Well, it's not how pattern rules in GNU make work. > The fact that gmake overwrites existing pattern rules is not > sufficient (as it does not permit to remove them) That is not the case. You can absolutely remove them. > and it is a non-compliance related to the original definition so > this modification from gmake causes unpredictable behavior. There is non-compliance with the POSIX standard. There are differences of implementation in areas that are not covered by the standard. There is no such thing as non-compliance with areas that are not covered by the standard. > Well after some searching (documentation could be better), I > discovered that gmake seems to disable (not to delete) pattern rules > if a rule with the same pattern but no command is defined. This is > not compliant to the definition of how pattern rules work. I don't understand the distinction you're trying to draw between "disabled" and "deleted". Regardless, if you define a pattern rule with no commands then the previous pattern is gone and cannot be "re- enabled", so I think "deleted" is the correct term. I think the docs are pretty clear: https://www.gnu.org/software/make/manual/html_node/Canceling-Rules.html > This is non-compliant behavior Pattern rules are not part of the POSIX standard, so "non-compliant behavior" is not an appropriate term. I'm happy to discuss incompatibilities between SunPro make/smake and GNU make as long as the discussion proceeds from a position that they are two co-equal implementations each with their own long history and (certainly in the case of GNU make) vast user bases that rely on the existing behaviors. However, I don't have the energy for discussions that begin with the premise that everything that exists in SunPro make/smake is canonical and any behavior in GNU make that differs from that is "non-compliant". > The series: > > %.o: %.c > echo some command > > %.o: %.c > > could be defined to require to completely remove the first definition > from the chain of pattern rules. That is already the way GNU make works. Although I don't know what you mean by the "first definition"; there can only be one instance of a given pattern rule (note, not one instance of a given pattern _target_; obviously many pattern rules may be defined with the same target). > As a result, the series: > > %.o: %.c > echo some command > > %.o: %.c > > %.o: %.c > echo some new command > > could be defined as to first define a pattern rule, then to > completely remove it from the chain of pattern rules and to finaly > add a new rule with a different command to the current end of the > pattern rule chain, without being completely incompatible to the > existing pattern rule specs. There is no single "spec" for pattern rules, there is only how SunPro make handles pattern rules and how GNU make handles pattern rules. In GNU make there's no need to delete the pattern rule before you define a new one. You just define the new one and it replaces the existing one. I don't see the point in requiring people to delete the pattern rule first. What does that buy you? > To fix this problem, the nonsense pattern with no command definition: > > %: % > > could be defined as the method to completely remove all existing > pattern rules from the current chain of pattern rules. Yes, that could be done. It's different than MAKEFLAGS += -r, however, because the latter is guaranteed to only delete the _built-in_ rules. This is almost always what the user wants. Having "%:%" delete ALL the existing pattern rules is problematic because it relies on a specific ordering of appearance in makefiles. I'm sure such a feature would lead to a lot of head-scratching followed by cursing once a stray "%:%" pattern was discovered down in the bowels of the makefile system. Possibly even accidentally as the result of a variable expanding to empty unexpectedly... A number of the enhancements to GNU make are intended to reduce the reliance on order of definition as much as possible. Users do want and rely on these enhancements. I would prefer to use a special target which forced all built-in / system rules (only) to be dropped, something like: .NOBUILTINS: This would provide the identical behavior as "make -r", but without modifying MAKEFLAGS. This seems like something that could easily be added to the standard as well, without even considering pattern ru
[1003.1(2004)/Issue 6 0001419]: Missing newline / indentation in .SCCS_GET default rule definition
The following issue has been SUBMITTED. == https://austingroupbugs.net/view.php?id=1419 == Reported By:psmith Assigned To:ajosey == Project:1003.1(2004)/Issue 6 Issue ID: 1419 Category: Shell and Utilities Type: Error Severity: Editorial Priority: normal Status: Under Review Name: Paul Smith Organization: GNU Project User Reference: Section:make Page Number: Line Number: Interp Status: --- Final Accepted Text: == Date Submitted: 2020-11-07 20:20 UTC Last Modified: 2020-11-07 20:20 UTC == Summary:Missing newline / indentation in .SCCS_GET default rule definition Description: Apologies for not including the page and line number: I'm not sure where to get a copy of the standard with this information included. The description of the .SCCS_GET special target says: he application shall ensure that this special target is specified without prerequisites. If this special target is included in a makefile, the commands specified with this target shall replace the default commands associated with this special target (see Default Rules). The commands specified with this target are used to get all SCCS files that are not found in the current directory. However, the example provided in the default rules section shows: .SCCS_GET: sccs $(SCCSFLAGS) get $(SCCSGETFLAGS) $@ This shows the commands as prerequisites of the special target, which is not correct. Desired Action: Change: .SCCS_GET: sccs $(SCCSFLAGS) get $(SCCSGETFLAGS) $@ to: .SCCS_GET: sccs $(SCCSFLAGS) get $(SCCSGETFLAGS) $@ == Issue History Date ModifiedUsername FieldChange == 2020-11-07 20:20 psmith New Issue 2020-11-07 20:20 psmith Status New => Under Review 2020-11-07 20:20 psmith Assigned To => ajosey 2020-11-07 20:20 psmith Name => Paul Smith 2020-11-07 20:20 psmith Organization => GNU Project 2020-11-07 20:20 psmith Section => make ==
[1003.1(2004)/Issue 6 0001420]: Clarification: where are internal macros available?
The following issue has been SUBMITTED. == https://austingroupbugs.net/view.php?id=1420 == Reported By:psmith Assigned To:ajosey == Project:1003.1(2004)/Issue 6 Issue ID: 1420 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Under Review Name: Paul Smith Organization: GNU Project User Reference: Section:make Page Number: Line Number: Interp Status: --- Final Accepted Text: == Date Submitted: 2020-11-07 20:27 UTC Last Modified: 2020-11-07 20:27 UTC == Summary:Clarification: where are internal macros available? Description: In the section "Internal Macros" we see: > The make utility shall maintain five internal macros that can be used in target and inference rules. It is not clear from this text what is meant by "can be used in ... rules". In GNU make for example, internal macros (called "automatic variables" in the GNU make manual) are available only within the commands of a rule but not available within the prerequisites of a rule. Does the statement "can be used in" mean to suggest that these macros can be used in the prerequisites list of a given rule as well? If so, we must clarify what it means when a non-$@ variable is used in the prerequisites list. Desired Action: Change the text: The make utility shall maintain five internal macros that can be used in target and inference rules. to: The make utility shall maintain five internal macros that can be used in the commands of target and inference rules. == Issue History Date ModifiedUsername FieldChange == 2020-11-07 20:27 psmith New Issue 2020-11-07 20:27 psmith Status New => Under Review 2020-11-07 20:27 psmith Assigned To => ajosey 2020-11-07 20:27 psmith Name => Paul Smith 2020-11-07 20:27 psmith Organization => GNU Project 2020-11-07 20:27 psmith Section => make ==
Re: [1003.1(2004)/Issue 6 0001419]: Missing newline / indentation in .SCCS_GET default rule definition
Austin Group Bug Tracker wrote in <8d658048f7dbed7f9cd0b38c954c2...@austingroupbugs.net>: |The following issue has been SUBMITTED. |== |https://austingroupbugs.net/view.php?id=1419 ... |Apologies for not including the page and line number: I'm not sure where to |get a copy of the standard with this information included. Interesting! I convert with pdftotext from "poppler", which i install only for that purpose. (But it is not that large.) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
[1003.1(2004)/Issue 6 0001420]: Clarification: where are internal macros available?
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1420 == Reported By:psmith Assigned To:ajosey == Project:1003.1(2004)/Issue 6 Issue ID: 1420 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Under Review Name: Paul Smith Organization: GNU Project User Reference: Section:make Page Number: Line Number: Interp Status: --- Final Accepted Text: == Date Submitted: 2020-11-07 20:27 UTC Last Modified: 2020-11-07 22:01 UTC == Summary:Clarification: where are internal macros available? == -- (0005103) joerg (reporter) - 2020-11-07 22:01 https://www.austingroupbugs.net/view.php?id=1420#c5103 -- Your seem to miss that the macros $< and $* are undefined in case of explicit rules. smake does not expand $< or $* for explicit rules. SunPro Make and gmake both expand these macros, but use completely incompatible rules to expand these macros in case of explicit rules. These rules result in the same expansion for some constraints and give different results for other constraints. Your text thus is inacceptable for standardization. BTW: The background for this question was a question from a bug-tracking system that has been caused by an incompatibility in the BSD make program and was related to the use of $@ in the dependency list of an explicit target rule. Make macros seen in the dependency list of a target rule are expanded by the parser already and at that time, $@ is undefined. Issue History Date ModifiedUsername FieldChange == 2020-11-07 20:27 psmith New Issue 2020-11-07 20:27 psmith Status New => Under Review 2020-11-07 20:27 psmith Assigned To => ajosey 2020-11-07 20:27 psmith Name => Paul Smith 2020-11-07 20:27 psmith Organization => GNU Project 2020-11-07 20:27 psmith Section => make 2020-11-07 22:01 joerg Note Added: 0005103 ==
