Paul Smith wrote, on 08 Sep 2021: > > On Tue, 2021-09-07 at 18:30 -0700, Nick Stoughton wrote: > > The problem we were trying to address with this change is that > > bsd make (bmake) and GNU make both have a := operator, but they > > behave differently. We originally added ::= to match the gmake > > behavior. The idea with :::= is to match the bmake behavior. > > OK, but that doesn't really answer my question. "We added this version > so now we have to add that version too or else it's not fair" doesn't > seem like a good reason to invent brand new syntax in the POSIX spec. > > There must be some reason for the BSD model to be added; there must be > some important or useful feature that it enables, that is impossible, > or difficult, or at least annoying to achieve in other ways. If this > was a feature that already existed (that is, the operator :::= was > already implemented and used by makefiles) then there's an argument for > adding it to the standard just to make it official: standardizing > existing practice has value.
You're looking at recent POSIX history at a too fine-grained level. In the current standard (Issue 7) the only assignment operator is plain =. We want to add support for some form of assignment that evaluates the right hand side at assignment time in Issue 8. There are two existing := operators that do this (gmake and BSD make), but in different ways. 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. > 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. 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. > > So, extracting from the etherpad of 2021-08-12: > > > Options: > > > > > > > > > 1. Add :::= with behavior of BSD := with $$ always preserved > > > (.MAKE.SAVE_DOLLARS either doesn't affect :::= or is an extension) > > > > > > > > > 2. Add :::= with behavior of BSD := with $$ never preserved > > > (.MAKE.SAVE_DOLLARS is an extension, nominally required to be false > > > by default if implemented so existing scripts don't break if > > > implementation applies it to additional assignment types other than > > > :::=, imo) > > > > > > > > > 3. Add :::= with behavior of BSD := with .MAKE.SAVE_DOLLARS, > > > default true > > > > > > > > > 4. Add :::= with behavior of BSD := with .MAKE.SAVE_DOLLARS, > > > default false > > > > > > > > > 5. Don't add :::= > > > > I believe we opted for #4. > > Based on my reading of the text actually appearing the in current > draft, it appears that the option chosen was #1 above, not #4: the text > says that "$$" is preserved and there's no mention of > .MAKE.SAVE_DOLLARS anywhere. Yes, we went with option 1. Our thinking here is that the original behaviour of BSD := whereby $$$$ is evaluated multiple times was a design fault, and the fix is to preserve $$ during the initial assignment. However, for backwards compatibility this couldn't be done as a straight change (because makefiles exist that double the number of $'s as a work-around and they would break), hence the introduction of .MAKE.SAVE_DOLLARS. Since the standard is adding :::= not :=, it doesn't have this backwards compatibility problem and so can just specify the "fixed" behaviour. -- Geoff Clare <[email protected]> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
