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. There is then some further confusion because
bmake also has the variable .MAKE.SAVE_DOLLARS. 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.

On Tue, Sep 7, 2021 at 5:19 PM Paul Smith via austin-group-l at The Open
Group <austin-group-l@opengroup.org> wrote:

> On Thu, 2021-08-12 at 15:19 +0000, Austin Group Bug Tracker wrote:
> > After page 2894 line 97263 add:
> >
> >     <blockquote>The following form defines a delayed-expansion macro
> > (replacing any previous definition of the macro named by
> > <i>string1</i>):
> >
> >     <tt><i>string1</i> :::= <b>[</b><i>string2</i><b>]</b></tt>
> >
> >     by immediately expanding macros in <i>string2</i>, if any, before
> > assigning the value.</blockquote>
> >
> > On page 2895 line 97310, change:
> >
> >     <blockquote>The macro $$ shall be replaced by the single
> > character
> > '$'.</blockquote>
> >
> > to:
> >
> >     <blockquote>The string "$$" shall be replaced by the single
> > character
> > '$', except during the immediate expansion performed for the :::=
> > operator,
> > where it shall be left unmodified.</blockquote>
>
> So I took a look at implementing this in GNU make since it seems to
> have been adopted.
>
> I just can't understand the point of this change.  Can someone provide
> me with some example(s) of this :::= operator showing how it might be
> used and what problems it is trying to solve?  The idea behind this
> completely escapes me so I'm wondering if I'm somehow misinterpreting
> the text above defining how :::= is supposed to work.
>
> I can sort of understand why someone might want to immediately expand a
> variable but then treat the expansion as delayed-expansion (although as
> I pointed out in the issue comments, you can already do this without
> this new operator you just have to use two variables, and I haven't had
> anyone ask me for this capability).
>
> But what is the point of having an immediately expanded variable where
> variables are expanded but "$$" is preserved?  This I can't really
> fathom.
>
> Also, it's not clear to me whether preserving the '$$' only applies to
> the unexpanded string, or also applies to the expansion of variables
> contained in the string.
>
> For example, what would be the expected result of this:
>
>   foo = one$$two
>   bar :::= $(foo) three$$four
>   all:;@echo '$(bar)'
>
> Is the internal value of the "bar" variable 'one$$two three$$four', so
> that the result of running make is:
>
>   one$two three$four
>
> or is the internal value of the "bar" variable 'one$two three$$four',
> so that the result of running make is:
>
>   onewo three$four
>
>
>
  • [Issue 8 dra... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [Issue 8 dra... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [Issue 8 dra... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [Issue 8 dra... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [Issue 8 dra... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [Issue 8 dra... Austin Group Bug Tracker via austin-group-l at The Open Group
  • Re: [Issue 8... Paul Smith via austin-group-l at The Open Group
    • Re: [Is... Geoff Clare via austin-group-l at The Open Group
      • Re:... Paul Smith via austin-group-l at The Open Group
  • Re: [Issue 8... Paul Smith via austin-group-l at The Open Group
    • Re: [Is... Nick Stoughton via austin-group-l at The Open Group
      • Re:... Paul Smith via austin-group-l at The Open Group
        • ... Geoff Clare via austin-group-l at The Open Group
          • ... Paul Smith via austin-group-l at The Open Group
            • ... David A. Wheeler via austin-group-l at The Open Group
              • ... Joerg Schilling via austin-group-l at The Open Group
              • ... David A. Wheeler via austin-group-l at The Open Group
              • ... Joerg Schilling via austin-group-l at The Open Group
              • ... Paul Smith via austin-group-l at The Open Group
              • ... Joerg Schilling via austin-group-l at The Open Group
              • ... David A. Wheeler via austin-group-l at The Open Group

Reply via email to