Re: More POSIX Issue 8 (next version) changes

[Roland Illig <roland.illig%gmx.de@localhost>]

Am 17.01.2023 um 17:41 schrieb Robert Elz:
> https://austingroupbugs.net/view.php?id=1436#c5496
>
> 	Adds the -j option to make.   I doubt there's anything in this which
> 	is different than what we do, but someone familiar with make should
> 	take a look and make sure.

I've read through all the comments, and they look good, with a single
exception.

In '-n' mode, NetBSD make runs command lines starting with '+'.  The
suggestion for line 98476 is to also run commands that contain the magic
string '${MAKE}' or '$(MAKE)'.  I'd like to preserve the current
behavior, as I don't see a need to have two separate mechanisms to
achieve the same goal.  The leading '+' is reliable, the proposed magic
strings aren't.

> https://austingroupbugs.net/view.php?id=1437#c5489
>
> 	More make ... I think this just adds mention of .NOTPARALLEL and .WAIT
> 	in the Rationale section, but once again ...

NetBSD make allows '.NOTPARALLEL: target' lines, while comment 0005489
suggests "without prerequisites".  Generating an error for them would be
trivial to implement, I don't know anything about real-world usage of
this directive though.

> https://austingroupbugs.net/view.php?id=1471#c5440
>
> 	More make ... adds :::= and +:= (or something like that).

I don't like them.  NetBSD make only knows a single kind of variables,
while GNU make distinguishes immediate variables from delayed variables.
 Adding these would make NetBSD make unnecessarily complicated.

> https://austingroupbugs.net/view.php?id=1479
>
> 	More make - should be just a clarification ...

Nothing to do from our side, the issue is about interpreting the default
rules, in our case from <sys.mk>.

> https://austingroupbugs.net/view.php?id=1513
>
> 	More make, things missed in earlier changes.

Again the ':::=' assignment operator.


> https://austingroupbugs.net/view.php?id=1520#c5556
>
> 	Even more make ... adds $^

Easy to implement, there's already a comment for '$^' in
usr.bin/make/var.c but no corresponding unit test.

> https://austingroupbugs.net/view.php?id=1505#c5616
>
> 	And yet more make (will this never end?) -- deals with expanding
> 	unset macros.

That's fine, no change to the current behavior.

> https://austingroupbugs.net/view.php?id=1549#c5754
>
> 	And we continue, more make, this one relating to escaped newlines
> 	in macro expansions.   I really don't want to know!

Interesting edge case, I didn't have a unit test for a backslash-newline
sequence _after_ macro expansion.  The suggestion from 0005754 also
doesn't seem to expect that the backslash-newline sequence can be
generated without occurring literally in the makefile.


Thank you for collecting all these proposed changes to POSIX regarding
make.  Even going through this curated list has already taken some time. :)

Roland