Re: I need support with a planned POSIX make extension

(Christos Zoulas) <[email protected]> wrote:

> >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?
> 
> I don't see an issue implementing them, but it feels to me that we are
> creating more of a mess this way, because very few people will understand
> and know which operator to use when and why.
> 
> I wish I could propose some more meaningful syntax, but if we are going
> to rely on just punctuation, I don't have any better ideas.

OK, I should explain the historical background to make it easier to understand 
the problem that you just might not see because you only know the bmake 
behavior.

We currently have 4 major make implementations plus the "make" found on AIX:

1)	smake	This is from 1980 and if you don't count the AIX make that
		is derived from the original make implementation from Stuart
		Feldman from 1976, smake is the oldest "modern" make 
		implementation.

2)	SunPro Make is a new implementation from scratch done in late 1985
		by Sun Microsystems. This is the first (non-research) make 
		that introduced a lot of new features, when it first has been
		published in January 1986. Since December 2006, SunPro Make
		is OpenSource after I asked Sun to do that.

3)	bmake	(Orignally pmake) from ~ 1988. It introduced several new 
		features from SunPro Make but not all of them

4)	gmake	from ~ 1989 copied most of the new features from SunPro Make
		but unfortunately introduced plenty of deviations/bugs.

The feature I am talking about in special, is available with the macro 
assignment operator := in bmake and gmake but gmake behaves in a way that 
nobody except some GNU followers seem to like the behavior of gmake here.

The obvious operator := for immediate expansion assinment is however not 
usable in a standardized environment. This is because years before bmake 
introduced := for that immediate expansion assinment purpuse, := was already
in use by SunPro Make for the purpose of a conditional macro assinment. So a
line like:

	foo := CFLAGS += -I../include

adds -I../include to CFLAGS for the time, the target foo is processed. And 
please note that in the 1980s SunPro Make definitely was the dominant make 
implementation. Smake implements := the same way as bmake, but warns about
using a nonportable assignement operator.

As a side note, it may be of interest, that during 37+ years of maintaining 
smake, I did never receive a request to implement the behavior found in gmake.

Because o the problem with :=, POSIX introduced ::= instead. My problem was 
that I assumed that the other people did like to introduced the uniform 
behavior of smake and bmake, and at that time, I did not know that gmake did
have a deviation in it's behavior from what bmake/smake do.

A year ago I realized the problem and I asked to fix that POSIX bug to no 
avail and this is why I implemented the new operator :::= with the behavior
of what smake/bmake implement with :=.

Given that bmake needs to implement ::= if it likes to follow POSIX and given 
that := is not usable because of it's non-uniform behavior, you have the 
chance to give up your current := behavior completely, or to implement :::=
as an alias for what smake/bmake implemented with := in 2011, when POSIX had
that unfortunate teleconference that decided to implement the gmake behavior 
with ::=, ignoring what the majority of make implementation do.

I hope that helps to better understand the background...

Jörg

-- 
EMail:[email protected]                  Jörg Schilling D-13353 Berlin
					Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/