Re: [RFC] Scoped variables, supercharged

[thutt]

Jouke Witteveen writes:
 > On Thu, Dec 26, 2019 at 10:52 PM Paul Smith <address@hidden> 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.