"David A. Wheeler via austin-group-l at The Open Group"
wrote:
> Allow me to *try* to bring this back to the original topic :-).
>
> I think it?s vital that ?::=?, as (provisionally) accepted *8* years ago, be
> in the final version.
> The underlying semantics of this (GNU make?s :=) are
On Thu, 2021-09-09 at 10:07 +0100, Geoff Clare via austin-group-l at
The Open Group wrote:
> You took a risk when you added ::= to gmake while it was only an
> ccepted proposal, not part of an approved revision to the standard.
> And gmake users who make use of it in the expectation that is will
>
Allow me to *try* to bring this back to the original topic :-).
I think it’s vital that “::=“, as (provisionally) accepted *8* years ago, be in
the final version.
The underlying semantics of this (GNU make’s :=) are widely used.
I don’t know if adding :::= and +:= operators is that vital. But
On Wed, Sep 08, 2021 at 03:19:57PM -0400, David A. Wheeler via austin-group-l
at The Open Group wrote:
>
> > Users of smake and BSD make write large and structured makefiles that use
> > plenty of include statements. This does not apply to gmake users and may be
> > the reason why gmake users
"David A. Wheeler via austin-group-l at The Open Group"
wrote:
> This is easily disproven using the Linux kernel & LibreOffice as examples.
>
> The Linux kernel is large & uses GNU make.
> Here?s the Linux main tree?s GitHub mirror: https://github.com/torvalds/linux
> Main Makefile:
Paul Smith wrote, on 08 Sep 2021:
>
> On Wed, 2021-09-08 at 09:29 +0100, Geoff Clare via austin-group-l at
> The Open Group wrote:
>
> > > 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
> On Sep 8, 2021, at 2:03 PM, Joerg Schilling via austin-group-l at The Open
> Group wrote:
>
> "David A. Wheeler via austin-group-l at The Open Group"
> wrote:
>
>>
>>> On Sep 8, 2021, at 1:06 PM, Joerg Schilling via austin-group-l at The Open
>>> Group wrote:
>>> Hasn't it been
"David A. Wheeler via austin-group-l at The Open Group"
wrote:
>
> > On Sep 8, 2021, at 1:06 PM, Joerg Schilling via austin-group-l at The Open
> > Group wrote:
> > Hasn't it been explained many times that the non-orthogonal behavior of
> > gmake
> > for the += operator for macros created
> On Sep 8, 2021, at 1:06 PM, Joerg Schilling via austin-group-l at The Open
> Group wrote:
> Hasn't it been explained many times that the non-orthogonal behavior of gmake
> for the += operator for macros created with the gmake := operator is a source
> of unpredictable behavior, in special
"Paul Smith via austin-group-l at The Open Group"
wrote:
> I asked for examples, or explanations of situations, where using the
> POSIX ::= operator as currently defined isn't sufficient, and the
> different behavior of the :::= operator is required instead.
Hasn't it been explained many times
On Wed, 2021-09-08 at 17:13 +0200, sch...@schily.net wrote:
> That as introduced by accident, because I did not realize at that
> time that gmake used an icompatible implementation that differs from
> smake and BSD make.
I don't see how it can be possible that there was any confusion about
this.
"David A. Wheeler" wrote:
> > That as introduced by accident, because I did not realize at that time that
> > gmake used an icompatible implementation that differs from smake and BSD
> > make.
>
> That?s an unfortunate bug but easily fixed. It *is* specifically noted in the
> Rationale :-).
> On Sep 8, 2021, at 11:13 AM, Joerg Schilling via austin-group-l at The Open
> Group wrote:
>
> "David A. Wheeler via austin-group-l at The Open Group"
> wrote:
>
>> I agree with Paul Smith. This was agreed on 8 years ago, and the widely-used
>> GNU make has
>> supported ::= as immediate
"Paul Smith via austin-group-l at The Open Group"
wrote:
> On Wed, 2021-09-08 at 11:10 +0200, Joerg Schilling via austin-group-l
> at The Open Group wrote:
> > The :::= operator has been implemented in two independent make
> > programs before it was standardized.
> >
> > The :::= operator was
"David A. Wheeler via austin-group-l at The Open Group"
wrote:
> I agree with Paul Smith. This was agreed on 8 years ago, and the widely-used
> GNU make has
> supported ::= as immediate expansion since 2013. That?s strong precedence.
> See the discussion here:
>
On Wed, 2021-09-08 at 11:10 +0200, Joerg Schilling via austin-group-l
at The Open Group wrote:
> The :::= operator has been implemented in two independent make
> programs before it was standardized.
>
> The :::= operator was introduced to smake and SunPro Make in March.
I can't consider this a
On Sep 8, 2021, at 9:53 AM, Paul Smith via austin-group-l at The Open Group
wrote:
> 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
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
"Paul Smith via austin-group-l at The Open Group"
wrote:
> 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
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
>
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 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
On Thu, 2021-08-12 at 15:19 +, Austin Group Bug Tracker wrote:
> After page 2894 line 97263 add:
>
> The following form defines a delayed-expansion macro
> (replacing any previous definition of the macro named by
> string1):
>
> string1 :::= [string2]
>
> by immediately
On Tue, 2021-09-07 at 15:06 +0100, Geoff Clare wrote:
> Already reported in https://austingroupbugs.net/view.php?id=1513
Oh thanks! I must have missed that in my inbox.
Paul Smith wrote, on 07 Sep 2021:
>
> On Thu, 2021-08-12 at 15:19 +, Austin Group Bug Tracker wrote:
> > A NOTE has been added to this issue.
> > ==
> > https://austingroupbugs.net/view.php?id=1471
> >
On Thu, 2021-08-12 at 15:19 +, Austin Group Bug Tracker wrote:
> A NOTE has been added to this issue.
> ==
> https://austingroupbugs.net/view.php?id=1471
>
The following issue has been set as RELATED TO issue 0001513.
==
https://austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned
The following issue has a resolution that has been APPLIED.
==
https://austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned
The following issue has been RESOLVED.
==
https://austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
The following issue has been SUBMITTED.
==
https://www.austingroupbugs.net/view.php?id=1471
==
Reported By:joerg
Assigned To:
63 matches
Mail list logo
