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 != example, i realize i misunderstood the meaning > of option one. Let me correct myself. > > 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. Otherwise, +:= and +:::= behave the same as +=". > If we go with this, then there is no need for +!=, because +!= would > behave as +=. Similarly, there is no need for +::=, because +::= > would behave as +:=.
I agree that we don't need to treat +:= and +::= differently. They are just different names for the same operator. I don't understand the point you are making about +!=. Maybe you're misremembering what the != operator does? Let's step back and I'll try to think more clearly about this. The variable assignment operators describe two things: how to handle the RHS value and what the resulting flavor of the variable will be. Although we have four assignment operators, once the assignment is complete there are only two flavors of variables: either recursive or simple: = - Don't expand the RHS, --> recursive variable := - Expand the RHS, --> simple variable ::= - Expand the RHS, --> simple variable :::= - Expand and escape the RHS, --> recursive variable != - Run the RHS as a shell script, --> recursive variable. If an appending operator is applied to a variable that doesn't exist already, then the behavior is the same as if we used the non-appending operator in all cases. So if the variable doesn't exist, "+=" behaves like "=", "+:=" behaves like ":=", "+::=" behaves like "::=", "+:::=" behaves like ":::=", and "+!=" behaves like "!=". That's simple. What about a variable that does exist already? I think that we can agree that the append operator cannot change the type of a variable that already exists. If the variable was recursive before it must stay recursive afterward; the same for simple variables. If we agree on the above then the only question is how the RHS of the assignment is treated in each case. For each possible appending operator we have to answer two questions: 1) What is the RHS behavior when appending to a RECURSIVE variable? 2) What is the RHS behavior when appending to a SIMPLE variable? We have to preserve the existing behavior for "+=". So for "+=", the answers must be: += Recursive: the RHS will be appended without expanding. Simple: the RHS will be expanded then appended. My understanding of your suggestion is that ALL the operators should behave the same as "+=" in this situation and the specific operator doesn't matter. I just don't think that will work. It will be almost impossible to use these appending operators reliably if this is how they behave. Here is a possible solution which will be hard to document, but will probably end up giving users what they expect: +:= Recursive: the RHS will be expanded and escaped then appended. Simple: the RHS is expanded then appended +::= Recursive: the RHS will be expanded and escaped then appended. Simple: the RHS is expanded then appended +:::= Recursive: the RHS will be expanded and escaped then appended. Simple: the RHS is expanded then appended +!= Recursive: the RHS will be run as a shell script then appended. Simple: the RHS is run as a shell script, expanded, then appended I believe that with this behavior you will always get the equivalent of, "the RHS is handled according to the assignment operator, and the expansion of the resulting variable will be as expected based on the flavor (recursive vs. simple)". The only one of these which is slightly off is the +!= to a simple variable since the result of the shell script cannot be stored as a recursive value. Instead I expand it immediately. I can provide examples of the results of this if needed for understanding; I'm working on a new regression test file for it. -- Paul D. Smith <psm...@gnu.org> Find some GNU make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist