On Wed, 2021-09-08 at 09:29 +0100, Geoff Clare via austin-group-l at The Open Group wrote: > Personally I see no reason to prefer one over the other. This leads > to three choices for what goes in Issue 8: > > 1. Just an operator that works like gmake := > 2. Just an operator that works like BSD make := > 3. Two operators, one like gmake := and one like BSD make := > > We have decided to go with option 3.
This is not the right way to look at it. If there truly is NO REASON to choose one over the other then it's wrong to standardize both because now you are just inventing two ways to do things which have no practical difference between them. If it was the case that lots of makefiles already used two DIFFERENT operators that did things differently, then there would be a good argument for adding both, so that lots of EXISTING makefiles could be made portable with no work on their part. That's a good goal. But unfortunately we do not have that happy situation here: here we have lots of makefiles that use the SAME operator that works differently, and no makefiles that implement :::= and so no makefiles will become portable by making this operator standard. Thus the only reason we should standardize both is if there IS some reason to choose the behavior of :::= over ::=. If there's no reason to choose one over the other, and makefiles have to change their operator to become standard anyway, then they can just change their operator to ::=. > > But here we're inventing an entirely new operator that NO VERSION > > of make currently implements (yes, I understand that BSD make has a > > different operator that works in this same way but that's not the > > same thing: no existing makefile today contains the :::= operator > > so every makefile that wants to use it will have to be changed, and > > in a way which is not backward-compatible with older versions of > > make). > > At the time that we accepted a proposal to add ::= no version of make > implemented it. So your argument applies equally to that addition. No, that's not right. In issue 7 there is no way to have any sort of immediate expansion in standard make. That's clearly something that users wanted (for the record note that I was not the one who wanted this standardized: I didn't propose it or push for it in any way; it was users who wanted this). The ::= operator added immediate expansion. That's certainly a useful addition, and worthy of creating a new operator for. The only legitimate (IMO) reason to add ANOTHER operator :::= is, as I've been trying to understand, there's some characteristic of that behavior that people would find useful enough to change their makefiles to use it, that they can't get by changing their makefiles to use ::= which is already accepted. > Just because the proposal for ::= was applied to an earlier Issue 8 > draft than :::= doesn't mean it has any claim to be treated > differently as part of the overall changes from Issue 7 to Issue 8. If we wanted to have that discussion we should have had it back before ::= was accepted. At this point, ::= DOES have a claim to be treated differently because there IS ample implementation precedent for it: as a result of the previous decision back in 2011, GNU make has been providing the ::= operator now for almost 8 years (released in GNU make 4.0 in October 2013). It can't be changed now. We could remove ::= from the standard and instead add :::= but that seems useless to me: there are real makefiles out there using ::= which would be made NON-PORTABLE by removing ::= from the standard.
