tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: I need support with a planned POSIX make extension



David Holland <dholland-tech%netbsd.org@localhost> wrote:

> On Mon, Aug 02, 2021 at 06:42:14PM +0200, Joerg Schilling wrote:
>  > Do you believe that POSIX should include a method to control whether $$ is 
>  > expanded with := or not?
> 
> I don't know the history of this (or at least, not without going and
> raking it up) but I'd say that $$ should never be expanded except at
> the final output stage. The purpose of $$ is to produce $ in the
> output, not cater to monstrosities like $$$$$$$$(VAR) that depend on
> knowing exactly how many and which eval stages are going to be applied
> to your text.

OK, from our discussions at the POSIX teleconferences, we came to the 
conclusion that using $$ is extremely rare but if you like to use it, 
expansion of $$ should be inhibited by default for immediate expand 
assignment. A need to know how many "recursive" expansions apply to a certain 
piece of text then would be a real problem.
 
As a result, we decided to standardize :::= to work the same as smake behaves
and bmake behaved before 2016 for :=, with the exception that $$ is never 
expanded. In other words:

POSIX will in future standardize :::= as if bmake did contain
.MAKE.SAVE_DOLLARS=true followed by a := assignment.

> I'm also kind of skeptical, since the issue is lazy vs. eager
> evaluation, that more varieties of assignment operator are going to do
> anything to improve the situation.

The idea is to standardize :::= is a result from the fact that today
:= has three different meanings (SunPro Make -> conditional assignment), 
(bmake/smake -> immediate expansion to a std make macro) and 
(gmake -> immediate expansion to a nonstandard no-expansion gmake macro).
In other words: := cannot appear in portable makefiles.

In 2011, the POSIX commitee decided to standardize ::= for the gmake :=
behavior as an accident, because it was not clear at that time, that gmake 
implements a strange behavior for += for nonstandard no-expansion gmake macros 
and that gmake does not behave the same way as bmake and smake.

Today, we agreed to standardize :::= like bmake := with .MAKE.SAVE_DOLLARS=true

So we now have:

	:=	Not usable in portable makefiles

	::=	gmake := behavior

	:::=	bmake := behavior with no need for backwards compatibility 

I was interested to also see +:= standardized as "immediate expansion text 
append", but the other people told me the fact that this is implemented by 
SunPro Make and smake since September 2020 only is "not sufficient" existing
practice.

Would you be willing to implement +:= in bmake?

BTW: The man current page for SunPro Make is here:

	http://schilytools.sourceforge.net/man/man1/make.1s.html

I am going to change :::= and +:= within approx. two weeks to not expand $$.

smake was already changed the same way yesterday, but the related version is 
not yet published.

Jörg

-- 
EMail:joerg%schily.net@localhost                  Jörg Schilling D-13353 Berlin
					Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/



Home | Main Index | Thread Index | Old Index