Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
On Fri, 2022-09-09 at 14:13 -0400, Paul Smith via austin-group-l at The Open Group wrote: > Ah OK. I don't have access to the text (as far as I know) so I > wasn't aware that it was defined that way. Sounds good. Oh I see the text in the minutes now. OK with me. Thanks.
Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
On Fri, 2022-09-09 at 17:13 +0100, Geoff Clare via austin-group-l at The Open Group wrote: > I assumed when you said "other internal macros" you weren't including > $+ because the addition for $+ is being described by reference to $^ > and so is subject to the same exception for .WAIT. Ah OK. I don't have access to the text (as far as I know) so I wasn't aware that it was defined that way. Sounds good.
Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
Paul Smith wrote, on 09 Sep 2022: > > On Fri, 2022-09-09 at 16:02 +0100, Geoff Clare via austin-group-l at > The Open Group wrote: > > > > $^ > > > > The $^ macro shall evaluate to the list of prerequisites > > > > for the current target, with any duplicates (except > > > > the first) removed. It shall be evaluated for both > > > > target and inference rules. If the list of > > > > prerequisites of the target contain any .WAIT special > > > > targets, the results of expanding $^ are unspecified. > > > > > > Thanks, but what about the other internal macros that may refer to > > > prerequisites? Don't we need to specify the .WAIT behavior for > > > those > > > as well? > > > > No need, because the description of .WAIT being added says "When > > .WAIT appears in a target rule as a prerequisite, it shall not itself > > be treated as a prerequisite". > > Are you saying that the implementations that keep .WAIT (or even change > its name) in $^ have been discovered to NOT keep .WAIT in $+ and so the > $+ macro doesn't need the above special exception saying that the > results are unspecified, and the standard can just affirm that .WAIT is > not present in $+? I assumed when you said "other internal macros" you weren't including $+ because the addition for $+ is being described by reference to $^ and so is subject to the same exception for .WAIT. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
On Fri, 2022-09-09 at 16:02 +0100, Geoff Clare via austin-group-l at The Open Group wrote: > > > $^ > > > The $^ macro shall evaluate to the list of prerequisites > > > for the current target, with any duplicates (except > > > the first) removed. It shall be evaluated for both > > > target and inference rules. If the list of > > > prerequisites of the target contain any .WAIT special > > > targets, the results of expanding $^ are unspecified. > > > > Thanks, but what about the other internal macros that may refer to > > prerequisites? Don't we need to specify the .WAIT behavior for > > those > > as well? > > No need, because the description of .WAIT being added says "When > .WAIT appears in a target rule as a prerequisite, it shall not itself > be treated as a prerequisite". Are you saying that the implementations that keep .WAIT (or even change its name) in $^ have been discovered to NOT keep .WAIT in $+ and so the $+ macro doesn't need the above special exception saying that the results are unspecified, and the standard can just affirm that .WAIT is not present in $+? That seems exceedingly odd to me but ok!
Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
Paul Smith wrote, on 09 Sep 2022: > > On Fri, 2022-09-09 at 10:19 +0100, Geoff Clare via austin-group-l at > The Open Group wrote: > > It's intentional. I tried 'all: a b a c' with the GNU, Solaris 11.4 > > and FreeBSD implementations and they all expanded $^ (or $> for > > FreeBSD) to 'a b c'. Are you suggesting that there are circumstances > > where one of these implementations might not preserve the order? > > No, but the GNU make documentation doesn't state this as a requirement. > It says: > > > $^ > > The names of all the prerequisites, with spaces between them. For > > prerequisites which are archive members, only the named member is > > used (see Archives). A target has only one prerequisite on each other > > file it depends on, no matter how many times each file is listed as a > > prerequisite. So if you list a prerequisite more than once for a > > target, the value of $^ contains just one copy of the name. This list > > does not contain any of the order-only prerequisites; for those see > > the ‘$|’ variable, below. > > So if the ordering is required I should update this documentation. Sound like a good idea. There could well be makefiles in existence that rely on the ordering (even if unintentionally). -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
Paul Smith wrote, on 09 Sep 2022: > > On Thu, 2022-09-08 at 17:50 -0400, Lawrence Velázquez via austin-group- > l at The Open Group wrote: > > On Thu, Sep 8, 2022, at 3:29 PM, Paul Smith via austin-group-l at The > > Open Group wrote: > > > I don't have visibility into the current proposed text for the > > > POSIX make definition, but can someone clarify how the .WAIT > > > prerequisites are to be treated when expanding internal macros like > > > $^, $+, $?, and even $< (if, for some weird reason, someone used > > > .WAIT as the first prerequisite)? > > > > > > Is it the case that they are required to ALWAYS be present? Or > > > required to NEVER be present? Or is the value of internal macros > > > not well-defined for prerequisite lists that contain .WAIT? > > > > The latest note on bug 514 begins, "On D2.1 page 2947 line 98895, > > after applying bug 1520, change...". So presumably the intended > > text is a synthesis of the results of 1520 [1] and 514 [2]: > > > > $^ > > The $^ macro shall evaluate to the list of prerequisites > > for the current target, with any duplicates (except > > the first) removed. It shall be evaluated for both > > target and inference rules. If the list of > > prerequisites of the target contain any .WAIT special > > targets, the results of expanding $^ are unspecified. > > > > [example omitted] > > Thanks, but what about the other internal macros that may refer to > prerequisites? Don't we need to specify the .WAIT behavior for those > as well? No need, because the description of .WAIT being added says "When .WAIT appears in a target rule as a prerequisite, it shall not itself be treated as a prerequisite". -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
On Thu, 2022-09-08 at 17:50 -0400, Lawrence Velázquez via austin-group- l at The Open Group wrote: > On Thu, Sep 8, 2022, at 3:29 PM, Paul Smith via austin-group-l at The > Open Group wrote: > > I don't have visibility into the current proposed text for the > > POSIX make definition, but can someone clarify how the .WAIT > > prerequisites are to be treated when expanding internal macros like > > $^, $+, $?, and even $< (if, for some weird reason, someone used > > .WAIT as the first prerequisite)? > > > > Is it the case that they are required to ALWAYS be present? Or > > required to NEVER be present? Or is the value of internal macros > > not well-defined for prerequisite lists that contain .WAIT? > > The latest note on bug 514 begins, "On D2.1 page 2947 line 98895, > after applying bug 1520, change...". So presumably the intended > text is a synthesis of the results of 1520 [1] and 514 [2]: > > $^ > The $^ macro shall evaluate to the list of prerequisites > for the current target, with any duplicates (except > the first) removed. It shall be evaluated for both > target and inference rules. If the list of > prerequisites of the target contain any .WAIT special > targets, the results of expanding $^ are unspecified. > > [example omitted] Thanks, but what about the other internal macros that may refer to prerequisites? Don't we need to specify the .WAIT behavior for those as well? I would imagine, for example, the same rule as above would be in effect for both the "$+" and "$?" internal macros (I guess for "$?" it's sort of implied that .WAIT can never be considered newer than the target, otherwise the target would always be rebuilt--but maybe that should be made explicit, I dunno).
Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
On Fri, 2022-09-09 at 10:19 +0100, Geoff Clare via austin-group-l at The Open Group wrote: > It's intentional. I tried 'all: a b a c' with the GNU, Solaris 11.4 > and FreeBSD implementations and they all expanded $^ (or $> for > FreeBSD) to 'a b c'. Are you suggesting that there are circumstances > where one of these implementations might not preserve the order? No, but the GNU make documentation doesn't state this as a requirement. It says: > $^ > The names of all the prerequisites, with spaces between them. For > prerequisites which are archive members, only the named member is > used (see Archives). A target has only one prerequisite on each other > file it depends on, no matter how many times each file is listed as a > prerequisite. So if you list a prerequisite more than once for a > target, the value of $^ contains just one copy of the name. This list > does not contain any of the order-only prerequisites; for those see > the ‘$|’ variable, below. So if the ordering is required I should update this documentation.
Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
Paul Smith wrote, on 08 Sep 2022: > > > https://austingroupbugs.net/view.php?id=514#c5962 > > - > > - > > On D2.1 page 2947 line 98895, after applying bug 1520, > > change:The $^ macro shall evaluate to the list of > > prerequisites for the current target.to:The > > $^ macro shall evaluate to the list of prerequisites for the current > > target, with any duplicates (except the first) removed. > > On D2.1 page 2947 after line 98895 add:$+The > > $+ macro shall be equivalent to $^, except that duplicates shall not > > be removed; all prerequisites shall appear in the order they were > > listed in the makefile > > This was closed before I had a chance to comment on the wording but a > few things: > > First, this text doesn't mention the .WAIT prerequisites that were > added as optional features; do we need to add text for how these are > included (or not) in $^? Or, are they just included like any other > prerequisite? > > Or did .WAIT not get included? I can't remember. This was the subject > of https://austingroupbugs.net/view.php?id=1520 which itself doesn't > mention the removal of duplicate entries, as the above text does. Lawrence answered this part (correctly). > Second, the wording of the $^ implies that when duplicates are seen the > it's always the first instance which is preserved and subsequent > instances are omitted, which means order is preserved. Is that > requirement intentional? It's intentional. I tried 'all: a b a c' with the GNU, Solaris 11.4 and FreeBSD implementations and they all expanded $^ (or $> for FreeBSD) to 'a b c'. Are you suggesting that there are circumstances where one of these implementations might not preserve the order? -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
On Thu, Sep 8, 2022, at 3:29 PM, Paul Smith via austin-group-l at The Open Group wrote: > I don't have visibility into the current proposed text for the POSIX > make definition, but can someone clarify how the .WAIT prerequisites > are to be treated when expanding internal macros like $^, $+, $?, and > even $< (if, for some weird reason, someone used .WAIT as the first > prerequisite)? > > Is it the case that they are required to ALWAYS be present? Or > required to NEVER be present? Or is the value of internal macros not > well-defined for prerequisite lists that contain .WAIT? The latest note on bug 514 begins, "On D2.1 page 2947 line 98895, after applying bug 1520, change...". So presumably the intended text is a synthesis of the results of 1520 [1] and 514 [2]: $^ The $^ macro shall evaluate to the list of prerequisites for the current target, with any duplicates (except the first) removed. It shall be evaluated for both target and inference rules. If the list of prerequisites of the target contain any .WAIT special targets, the results of expanding $^ are unspecified. [example omitted] [1]: https://austingroupbugs.net/view.php?id=1520#c5556 [2]: https://austingroupbugs.net/view.php?id=514#c5962 -- vq
Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
On Thu, 2022-09-08 at 20:58 +0200, Steffen Nurpmeso wrote: > |First, this text doesn't mention the .WAIT prerequisites that were > |added as optional features; do we need to add text for how these > are > > Optional? .WAIT:? Only to be victorious over Borisorious! I went back through that (long) issue in Mantis and recalled that indeed it was not optional. I don't have visibility into the current proposed text for the POSIX make definition, but can someone clarify how the .WAIT prerequisites are to be treated when expanding internal macros like $^, $+, $?, and even $< (if, for some weird reason, someone used .WAIT as the first prerequisite)? Is it the case that they are required to ALWAYS be present? Or required to NEVER be present? Or is the value of internal macros not well-defined for prerequisite lists that contain .WAIT?
Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
psm...@gnu.org wrote in <2f4c249e139c3391ae56f0027cde10df76292bfa.ca...@gnu.org>: |On Thu, 2022-09-08 at 15:53 +, Austin Group Bug Tracker via austin- |group-l at The Open Group wrote: |> (0005962) geoffclare (manager) - 2022-09-08 15:53 |> https://austingroupbugs.net/view.php?id=514#c5962 |> - |> - |> On D2.1 page 2947 line 98895, after applying bug 1520, |> change:The $^ macro shall evaluate to the list of |> prerequisites for the current target.to:The |> $^ macro shall evaluate to the list of prerequisites for the current |> target, with any duplicates (except the first) removed. |> On D2.1 page 2947 after line 98895 add:$+The |> $+ macro shall be equivalent to $^, except that duplicates shall not |> be removed; all prerequisites shall appear in the order they were |> listed in the makefile | |This was closed before I had a chance to comment on the wording but a |few things: | |First, this text doesn't mention the .WAIT prerequisites that were |added as optional features; do we need to add text for how these are Optional? .WAIT:? Only to be victorious over Borisorious! --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)
Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
On Thu, 2022-09-08 at 15:53 +, Austin Group Bug Tracker via austin- group-l at The Open Group wrote: > (0005962) geoffclare (manager) - 2022-09-08 15:53 > https://austingroupbugs.net/view.php?id=514#c5962 > - > - > On D2.1 page 2947 line 98895, after applying bug 1520, > change:The $^ macro shall evaluate to the list of > prerequisites for the current target.to:The > $^ macro shall evaluate to the list of prerequisites for the current > target, with any duplicates (except the first) removed. > On D2.1 page 2947 after line 98895 add:$+The > $+ macro shall be equivalent to $^, except that duplicates shall not > be removed; all prerequisites shall appear in the order they were > listed in the makefile This was closed before I had a chance to comment on the wording but a few things: First, this text doesn't mention the .WAIT prerequisites that were added as optional features; do we need to add text for how these are included (or not) in $^? Or, are they just included like any other prerequisite? Or did .WAIT not get included? I can't remember. This was the subject of https://austingroupbugs.net/view.php?id=1520 which itself doesn't mention the removal of duplicate entries, as the above text does. Second, the wording of the $^ implies that when duplicates are seen the it's always the first instance which is preserved and subsequent instances are omitted, which means order is preserved. Is that requirement intentional? I think I'm confused :).
