On Saturday, January 27, 2024 4:14 PM, Paul Smith wrote: >On Sat, 2024-01-27 at 15:52 -0500, rsbec...@nexbridge.com 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 some >> > other makefile, potentially far away. >> >> Intuitive reading of this would seem that "bar=2 2 3" is better, as >> +:= should force complete resolution of the string applied to bar, >> not partial resolution of foo keeping an instance of $(foo) for >> resolution later. > >Hm, maybe I'm just weird. Or maybe I chose a poor example. > >What if the example was like this: > > foo_ARGS = -a > bar_ARGS = -b > ARGS = $($@_ARGS) -x > > all: foo bar > foo bar: ; cmd $(ARGS) $@ > > ARGS +:= $(shell gen-args) > >where the "gen-args" program outputs "-z". > >and now the value of ARGS would either be "$($@_ARGS) -x -z" using the method I >was suggesting, or it would be " -x -z" using the alternative method where ARGS >was converted into a simple variable. > >So using the first method make would run: > > cmd -a -x -z foo > cmd -b -x -z bar > >and using the alternative method make would run: > > cmd -x -z foo > cmd -x -z bar > >Is it still more intuitive? Maybe the answer is "well, just don't do that" >:). Or maybe >"+!=" could be used in this specific situation, but you get the idea. > >The problem is that when you write the assignment +:= it's not always so >simple to >know what the side-effects might be because you don't know what the current >behavior of the variable is, and it might change in the future. Of course, >that's >always a problem with makefiles.
My take on it is that +:= (because of the : ) means that you have to resolve everything at that point. So whatever ARGS might be when +:= is encountered, it is resolved completely. The result of ARGS prior to applying +:= could be anything, but +:= appends -z to whatever its current value is. The problem is that foo bar: ; cmd $(ARGS) is not resolved until the end of parse, but the value of ARGS just after recipe is resolved and applies to the command. If that is not correct, maybe do not do this.
