Jouke Witteveen writes: > On Thu, Dec 26, 2019 at 10:52 PM Paul Smith <psm...@gnu.org> wrote: > >
<snip> > > I believe thutt is thinking of creating new scopes in makefiles themselves, > > not within a variable/function context, for example within included > > makefiles or even within subsections of a particular makefile. Yes. > Ah, now I understand. With $(let), the scope is determined by the > parentheses, but theoretically, a file-scope could be a thing too. > > > For example something where you could say: > > > > FOO = bar > > > > push scope > > local FOO = baz > > > > $(FOO): blah > > pop scope > > > > $(FOO): yuck > > > > Of course if you wanted to write a bunch of define/endif stuff and use eval > > you could use $(let ...) to do something like this but it can get pretty > > gross. > > Let's run a little test. I have a Makefile containing: > ---- > X=global > $(let X,local,$(eval include inc.mk)) > $(info $X) > ---- > And a file callend inc.mk containing: > ---- > $(info $X) > X=included > $(info $X) > ---- > We can see what happens even without recompiling make by replacing the > instance of $(let) by $(foreach). The resulting behavior is the same > (because 'local' is only one word). We get the following: > ---- > $ make > local > local > included > ---- Interesting. I'd like to raise a few points. o I would find it objectionable to have to $(eval) the include of files to gain scoping. At the very least, this would adversely affect the readability of Makefiles. o I don't think this meachanism correctly captures scoping. The state of $(X) can be set by the master Makefile, or by an include file. Furthermore, it can be changed by another included file. But, the actual use of $(X) in a recipe can be deferred to much later. If there are several locations that set $(X) to a different value, what value will be used when the recipe is expanded? <snip> > One way to think of why $(let) would be a reasonable addition to make > is precisely because it does not deviate from established behavior too > much. Yet, it provides a clear value. Outside of the scoping, it also > enables basic list unpacking similar to `read` in the shell. My > example with reverse demonstrates this aspect too. I agree that there is a clear value. But I still caution that it should not be confused with full semantic scoping in a whole build system implemented in Make. -- My New Years Resolution is 4K.
