Re: [RFC] Scoped variables, supercharged

[thutt]

Jouke Witteveen writes:
 > On Thu, Dec 26, 2019 at 6:13 PM <address@hidden> wrote:
 > > Jouke Witteveen writes:
 > >  > I would like make to have scoped variables. Here, I will propose an
 > >  > implementation of them. This implementation is currently without tests 
 > > and
 > >  > documentation. Hopefully, the proposal is acceptable and I can add the
 > >  > tests and documentation.
 > >  >
 > >  > Consider a situation in which we have macros F and G, and some variable 
 > > X,
 > >  > and our makefile includes:
 > >  >
 > >  >   $(call F,$(call G,$(X)),$(call G,$(X)))
 > >
 > >  Your proposal has the potential to create variables that would have
 > >  scope local to a single invocation of a user-defined function, but it
 > >  wouldn't provide scoping to Make-proper.  For that reason alone, I
 > >  would suggest narrowing down the naming of the feature.  Perhaps
 > >  something like:
 >
 > What other meaning of 'scoping to Make-proper' do you have in mind? I
 > fail to see a scoping scenario that is not covered by my $(let)
 > proposal.
 >
 > >    Function local variables

 As Paul pointed out, regular Makefile variables have a single global
 scope.  For example, the canonical 'CC' variable is global.  Changing
 it affects everything in the entire Makefile (include-ed files, too).

 The flat namespace of Make gets crowded pretty quickly.  Consider if
 you want to have certain flags set in CFLAGS for a set of files, and
 other mutually exclusive flags set for other files.  As a
 hypothetical example, think about compiling some files for x86-64
 architecture, and others for Arm32.  Without using recursive
 invocation of Make.

 > Except that it has nothing to do with functions. Instead of the call
 > statements in my example, you can think of any long statement that
 > uses the same substatement (that has no side-effects) multiple times.

I see.  If you write Makefiles with a lot of Gnu Make extensions, this
would be handy.  I use I don't put a lot of But, I generally write Makefiles to 
look as regular
as possible.  So, expansion of

 >
 > >  Have you considered how this might affect target- and
 > >  pattern-specific variables?
 > >
 > >  What would the affect be of a local variable overriding the name of a
 > >  global variable?
 >
 > Global variables are shielded in the same way that $(call ...) shields
 > $0, $1, $2, ... in nested invocations.

 Are you sure?  If I set the value of CC to '/usr/bin/python' with
 $(eval), what will happen?


--
My New Years Resolution is 4K.