On Thu, 2021-09-02 at 16:28 +0000, Austin Group Bug Tracker wrote:
> On page 2975, insert before line
> 98708:<blockquote><b>.NOTPARALLEL</b><blockquote>The application
> shall ensure that this special target is specified without
> prerequisites or commands.

What exactly is required by an implementation to meet this "shall
ensure" statement?

Does this mean make implementations must generate a fatal error of some
kind if there are prerequisites or commands to .NOTPARALLEL (and
.POSIX: target is specified)?

It's quite simple to imagine adding a capability that, for example,
allows you to specify prerequisites of .NOTPARALLEL and have it do
useful things.  Requiring a fatal error if someone adds .POSIX: seems
overly strict.

> On page 2975, insert before line
> 98742:<blockquote><b>.WAIT</b><blockquote>The application shall
> ensure that this special target, if specified as a target, is
> specified without prerequisites or commands. When <b>.WAIT<b> appears
> as a target, it shall have no effect. When <b>.WAIT</b> appears in a
> target rule as a prerequisite, it shall not itself be treated as a
> prerequisite; however, <i>make</i> shall not recursively process the
> prerequisites to the right of the <b>.WAIT</b> until the
> prerequisites to the left of it have been brought up-to-date.
> Implementations may also enforce the same ordering between the
> affected prerequisites while processing other target rules that
> have some or all of the same affected
> prerequisites.</blockquote></blockquote>

For my clarification, what is the behavior for a rule like this:

    target: .WAIT prereq ; :

Am I right in assuming that the above text means that this is a no-op
and identical in behavior to:

    target: prereq ; :

because there are no "prerequisites to the left of the .WAIT"?

Similarly, I assume that this:

    target: prereq .WAIT ; :

is also a no-op since there are no "prerequisites to the right of the
.WAIT"...?

  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
    • Re: [10... Robert Elz via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • Re: [1003.1(... Paul Smith via austin-group-l at The Open Group
    • Re: [10... Geoff Clare via austin-group-l at The Open Group
      • Re:... Paul Smith via austin-group-l at The Open Group
        • ... Steffen Nurpmeso via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to