[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: foreach/ordering help
From: |
Paul D. Smith |
Subject: |
Re: foreach/ordering help |
Date: |
Sun, 3 Nov 2002 00:02:57 -0500 |
%% Russell <address@hidden> writes:
>> >> CSRCS = file1.c file2.c file999.c file1000.c
>> >> c.pfs:
>> >> @rm -f $@
>> >> @$(foreach f,$(CSRCS),$(shell echo $(f) >> $@))
r> I think each line of the command is spawned as a separate shell
r> process. Try to keep all the commands in one line (one process):
>> He's using make commands like $(foreach ...) and $(shell ...), and those
>> are evaluated by make before the command script is actually invoked.
>>
>> So, what you're suggesting won't help...
r> But wouldn't the line: @$(foreach f,$(CSRCS),$(shell echo $(f) >>
r> $@)) end up as a series of shell commands?
It does, but you have to keep in mind that $(shell ...) is executed
_when it's expanded_.
What does make do when it wants to run a command script? It expands
all the variables in the script. _Then_ it runs the script. Since the
$(shell ...) commands are invoked when expanded, they are all run
_before_ the command script (the rm operation) is run.
r> I thought it would then be more logical to execute all the shell
r> commands beginning from the start:
r> @rm -f $@ ; \
r> $(foreach f,$(CSRCS),$(shell echo $(f) >> $@))
r> Is this quirk of execution order stated in the manual? I'd
r> consider it a bug fix if that quirk wasn't so.
It's not a quirk, and it's not a bug. It's a natural extension of the
fact that (a) make functions are evaluated just like variables are, and
(b) all make variables (and functions) in a command script are (must
be!) expanded before make can invoke that command script.
--
-------------------------------------------------------------------------------
Paul D. Smith <address@hidden> 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
RE: foreach/ordering help, Randy W. Sims, 2002/11/03