Jouke Witteveen writes: > On Thu, Dec 26, 2019 at 6:13 PM <th...@vmware.com> 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.
