On Sun, 2024-02-18 at 22:23 +0100, Jouke Witteveen wrote:
> On Sun, Feb 4, 2024 at 12:05 AM Paul Smith wrote:
>
>
> I feel these proposals are
> 1) not obvious in how they work, regardless of how they work, and
> 2) largely possible without new syntax.
>
> The first of these is proven by the am
On Sun, Feb 4, 2024 at 12:05 AM Paul Smith wrote:
>
> On Sat, 2024-02-03 at 17:45 -0500, Paul Smith wrote:
> > Here's how I think the "append changes the type of the variable"
> > option works:
>
...
>
> Sorry for the possible confusion.
>
I feel these proposals are
1) not obvious in how they wor
On Sat, 2024-02-03 at 17:45 -0500, Paul Smith wrote:
> Here's how I think the "append changes the type of the variable"
> option works:
I should have been more clear on my nomenclature. In my examples the
column on the right is meant to describe what make has in its memory
for a variable. So if
On Mon, 2024-01-29 at 09:52 +, Edward Welbourne wrote:
> Perhaps it would be useful to enumerate the other types of assignment
This seems useful. There are two options: the "append changes the type
of the variable" option, and the "append doesn't change the type of the
variable" option. Since
Paul Smith (27 January 2024 21:32) wrote:
> I'm interested in peoples' opinions about which of these two
> implementations they would feel to be more "intuitive" or "correct".
> Also please consider issues of "action at a distance" where a variable
> is assigned in one makefile and appended to in s
On Sun, 2024-01-28 at 18:06 -0500, rsbec...@nexbridge.com wrote:
> > FOO +:= bar
> >
> > can be interpreted as working like this:
> >
> > FOO := $(FOO) bar
> >
> > which is what you and others are arguing for. Or it can be
> > interpreted as working
> > like this:
> >
> > __FOO :=
On Sunday, January 28, 2024 5:36 PM, Paul Smith wrote:
>On Sat, 2024-01-27 at 17:45 -0500, rsbec...@nexbridge.com wrote:
>> My take on it is that +:= (because of the : ) means that you have to
>> resolve everything at that point.
>
>Yes, I understand what you are saying. The question is, is that t
On Mon, 2024-01-22 at 21:33 -0500, Dmitry Goncharov wrote:
> On Mon, Jan 22, 2024 at 8:16 AM Paul Smith wrote:
> > I don't understand the point you are making about +!=.
>
> If all new operators behave the same as +=, when the variable exists,
> then +!= is not needed, because +!= would do the sa
On Sat, 2024-01-27 at 17:45 -0500, rsbec...@nexbridge.com wrote:
> My take on it is that +:= (because of the : ) means that you have to
> resolve everything at that point.
Yes, I understand what you are saying. The question is, is that the
right conception? Here's another way to look at it:
On Mon, 2024-01-22 at 08:15 -0500, Paul Smith wrote:
> Let's step back and I'll try to think more clearly about this.
Sorry for the delay in replying.
I can see that I was thinking about this one way but there's another
way to look at it that I didn't think of. We are talking only about
(a) appe
On Mon, Jan 22, 2024 at 8:16 AM Paul Smith wrote:
> I don't understand the point you are making about +!=.
If all new operators behave the same as +=, when the variable exists, then
+!= is not needed, because +!= would do the same as +=$(shell ...).
Based on your explanations, it looks like you
On Mon, Jan 22, 2024 at 4:59 PM Martin Dorey
wrote:
>
> Why is that?
>
>
> I imagine because that's how, to my surprise, it is today:
>
> martind@stormy:~/tmp/make-conditional-assignment-2024-01-22$ cat Makefile
> A := 42
> A += $(shell hello)
> martind@stormy:~/tmp/make-conditional-assignment-202
onday, January 22, 2024 07:27
To: psm...@gnu.org
Cc: Dmitry Goncharov ; bug-make
Subject: Re: New conditional assignment facility
* EXTERNAL EMAIL *
On Mon, Jan 22, 2024 at 2:16 PM Paul Smith wrote:
> > If the only goal was to allow +:= create a simple variable, then can
> > we
On Mon, Jan 22, 2024 at 2:16 PM Paul Smith wrote:
> > If the only goal was to allow +:= create a simple variable, then can
> > we do the following?
> > "If no variable with this name exists, then +:= creates a simple
> > variable, and +:::= creates an immediately-expanded-and-escaped
> > variable.
On Sun, 2024-01-21 at 14:22 -0500, Dmitry Goncharov wrote:
> Let us clarify the goal of these enhancements?
> i assumed that the goal of these enhancements was to allow code like
> hello+:=$(world)
> create 'hello' as a simple variable, if 'hello' does not exist yet.
>
> After reading your != exam
On Sun, Jan 21, 2024 at 11:17 AM Paul Smith wrote:
> I think you wrote that wrong: I think you mean "otherwise +:= behaves
> the same as +="... ?
You are right.
Let us clarify the goal of these enhancements?
i assumed that the goal of these enhancements was to allow code like
hello+:=$(world)
c
On Sat, 2024-01-20 at 22:18 -0500, Dmitry Goncharov wrote:
> > Either we could follow the example of "+=" and say that the assignment
> > type in "+:=" only takes effect if the variable doesn't already have a
> > type but if it does that type is preserved, so in the above example FOO
> > would cont
On Thu, Jan 11, 2024 at 7:55 AM Paul Smith wrote:
> So the new confusion becomes, what happens if you use "+" to append to
> an existing variable that has a different type?
>
> Due to decades of history (and, to be honest, significant technical
> incentive), we have to say that in this case:
>
>
Hi Paul,
On 1/11/24 14:38, Paul Smith wrote:
On Thu, 2024-01-11 at 14:28 +0100, Alejandro Colomar wrote:
alx@debian:~/tmp$ cat Makefile
var ?= foo
var ?+= bar
$(info $(var))
alx@debian:~/tmp$ make-9000
foo bar
make: *** No targets. Stop.
On Thu, 2024-01-11 at 14:28 +0100, Alejandro Colomar wrote:
> > > alx@debian:~/tmp$ cat Makefile
> > > var ?= foo
> > > var ?+= bar
> > > $(info $(var))
> > > alx@debian:~/tmp$ make-9000
> > > foo bar
> > > make: *** No targets. Stop.
> > > alx@debian:~/tmp$ make-9000 var=foo
> >
On Thu, Jan 11, 2024 at 02:25:25PM +0100, Alejandro Colomar wrote:
> On Thu, Jan 11, 2024 at 02:22:19PM +0100, Alejandro Colomar wrote:
> > Hi Paul!
> >
> > On Thu, Jan 11, 2024 at 01:44:19AM -0500, Paul Smith wrote:
> > > I've implemented a new capability for conditional assignments (not
> > > pu
On Thu, Jan 11, 2024 at 02:22:19PM +0100, Alejandro Colomar wrote:
> Hi Paul!
>
> On Thu, Jan 11, 2024 at 01:44:19AM -0500, Paul Smith wrote:
> > I've implemented a new capability for conditional assignments (not
> > pushed yet).
> >
> > After these changes, a "?" can precede any type of assignme
Hi Paul!
On Thu, Jan 11, 2024 at 01:44:19AM -0500, Paul Smith wrote:
> I've implemented a new capability for conditional assignments (not
> pushed yet).
>
> After these changes, a "?" can precede any type of assignment
> operation, not just "=", and make it conditional (that is, it only
> takes e
On Thu, 2024-01-11 at 01:44 -0500, Paul Smith wrote:
> I've implemented a new capability for conditional assignments (not
> pushed yet).
>
> After these changes, a "?" can precede any type of assignment
> operation, not just "=", and make it conditional (that is, it only
> takes effect if the vari
> I'm pretty uncomfortable with this inversion of expectation,
Indeed.
This inversion sounds confusing and that use case is already possible,
just not with a 'shortcut' notation.
> Or maybe we should say the "?+=" operator isn't supported and give an
> error since it has no function
that also le
I've implemented a new capability for conditional assignments (not
pushed yet).
After these changes, a "?" can precede any type of assignment
operation, not just "=", and make it conditional (that is, it only
takes effect if the variable is not already set).
So for example, in addition to "?=" wh
26 matches
Mail list logo
