Re: I need support with a planned POSIX make extension

["Simon J. Gerraty" <sjg%juniper.net@localhost>]

> I am currently trying to get an orthogonal extension into POSIX make in order
> to have at least an orthogonal variant as a choice instead of the incompatible
> GNU make extensions called:
> 
>         := that has been standardized in POSIX as ::= and that creates a
>            different type of make macro with different behavior

POSIX seems to have lost all value at this point.

> 
>         += from GNU make that is incompatible to the much older += from
>            SunPro Make. The incompatibility is that if a make macro has been
>            created by the GNU := (POSIX ::=) instead of the standard
>            assignment operaror =, += first expands the right side before
>            appending the expanded result to the macro.

A completely unnecessary complication.

>         The different type of macros created with the GNU := is not
>         expanded at use time.
> 
> The incompatible behavior from GNU make has the following problems:
> 
> 1)      expansion always could be prevented in a standard compliant way
>         by using $$(MACRO), instead of using a different macro type.

There is also nothing wrong with simply doing

VAR += ${FOO}
VAR := ${VAR}

if/when necessary.

All the above seems pointless obfuscation.

> 
> 2)      large makefiles that make heavy use of the include directive
>         become highly unpredictable because you cannot know what a +=
>         operator will do, since the first definition of the related make
>         macro is most likely in a different include file.
> 
>         I already filed a bug against POSIX for that and POSIX now recommends
>         to include at least one lower case letter in the name of a make
>         macro created via GNU make := (POSIX ::=).
> 
> 3)      The GNU make documentation is written so badly that most people
>         who use := do not know that this causes unexpected behavior with
>         the += operator.
> 
> In order to have at least the choice of an orthogonal way of doing what
> people expect, I defined and implemented two new operators:
> 
>         :::=    Assigns to a make macro by first expanding the right
>                 side of the assignment, but without creating a different
>                 type of make macro.

How does this help the already muddy waters?
How is this different to traditional := ?
 
>         +:=     Appends to a make macro by first expanding the right
>                 side of the assignment, regardless of the type of the
>                 make macro that is to the left.

This also seems like an unecessary compilcation.
 
> and I filed a bug against POSIX to enhance the standard to include these
> new operators, see:
> 
>         https://urldefense.com/v3/__https://www.austingroupbugs.net/view.php?id=1471__;!!NEt6yMaO-gk!VfmqyGT0fHZnPH7qOip8E1z3qDNtM9hxcRLaG-t6n_RqeummrqgrAQ8t2RfTBA$
> 
> BTW: I am the author and maintainer of smake and I am the current maintainer
> of SunPro Make as well. Both programs are part of the schilytools package
> and already include support for the new operators.
> 
> The time to implement the new operators was 1-4 hours for each of the make
> implementations, so this is a really cheap extension.

No it isn't.  The cost is not the time to add the feature to make.

It is all the  confusion and angst any makefile using these new
assignments will cause.

The real fix is to undo the damage caused by re-defining what := does
The gmake behavior seems like a bug - not something to emulate.

> Given that bmake otherwise behaves like smake for :=, I hope that *BSD could
> be willing to support my enhancement.
> 
> So my question is: would you be willing to implement support for :::= and +:=
> into bmake and publish that will to the POSIX bug tracking system?

Sorry, to me this seems like just making a bad situation worse.

--sjg