Alexey Neyman <[EMAIL PROTECTED]> writes:
> ============================================
> $(warning "selector: $(selector)")
> ifneq ($(selector),)
> override selector :=
> endif
> $(warning "selector: $(selector)")
>
> aaa:
> $(MAKE) selector=abc bbb
>
> bbb:
> $(MAKE) ccc
>
> ccc:
> ============================================
>
> The "make aaa" command produces the following output:
> Makefile:1: "selector: "
> Makefile:5: "selector: "
> make selector=abc bbb
> make[1]: Entering directory `/home/avn/tmp'
> Makefile:1: "selector: abc"
> Makefile:5: "selector: "
> make ccc
> make[2]: Entering directory `/home/avn/tmp'
> Makefile:1: "selector: abc"
> Makefile:5: "selector: "
> make[2]: Nothing to be done for `ccc'.
> make[2]: Leaving directory `/home/avn/tmp'
> make[1]: Leaving directory `/home/avn/tmp'
>
> That is, the lowest sub-make receives selector=abc, though the 2nd
> sub-make overrided it with empty string. Is it right behavior? If so,
> how could one prevent a variable from being exported to sub-make
> processes? (unexport selector does not help either).
IMO, it's a bug in GNU make (confirmed with make from cvs). Paul, what do
you think?
Also I came up with the following workaround:
$(warning "selector: $(selector)")
ifneq ($(selector),)
override selector :=
endif
$(warning "selector: $(selector)")
export selector
ifeq ($(MAKECMDGOALS),aaa)
selector := abc
endif
aaa:
$(MAKE) bbb
bbb:
$(MAKE) ccc
ccc:
_______________________________________________
Help-make mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/help-make
