%% John Graham-Cumming <[EMAIL PROTECTED]> writes: jg> Martin d'Anjou wrote:
>> l:=$(shell echo $$VAR) >> $(warning VAR=$(VAR)) >> export VAR=10 >> l:=$(shell echo $$VAR) >> $(warning VAR=$(VAR)) >> Why would VAR be defined for $(shell) just like it is for >> $(warning) for example? Without export, ok, but with export, why >> not? jg> I think the authors of GNU Make want to avoid the following jg> situation: jg> export FOO=$(shell do_something) jg> export BAR=$(shell do_something_else) jg> What should the values of FOO and BAR be in the environment for jg> each of those shell commands? It's hard to answer because in jg> order to run the shell you'd have to figure out the value of FOO jg> and BAR to put into the environment, which requires a $(shell) jg> which requires... a loop. There is a regression test in the suite: export HI = $(shell echo hi) .PHONY: all all: ; @echo $$HI Today, this works and does the "expected" thing (prints "hi"). If the simple, obvious change is made to the code to use the "normal" invocation of a process that sets up the environment using make's normal rules (to export variables) this makefile starts looping forever until it runs out of memory or something. This is the same issue that John mentions above, formulated slightly differently. In order for exporting of variables the $(shell ...) to work, some way of breaking this recursion would need to be implemented. Obviously that is not an unsolvable problem but no one has gotten around to it yet. It would also be a backward-incompatible change, but probably that's something that could be lived with. -- ------------------------------------------------------------------------------- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
