Source-Changes-D archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/usr.bin/make
- Subject: Re: CVS commit: src/usr.bin/make
- From: David Laight <david%l8s.co.uk@localhost>
- Date: Wed, 9 Jun 2010 20:44:45 +0100
On Wed, Jun 09, 2010 at 06:45:35PM +0000, Christos Zoulas wrote:
> >
> >This is wrong. Loop variables are not exapnded on each loop iteration.
> >Each loop iteration effectively creates a new variable. The rest of his
> >confusion comes from two simple facts:
> >(1) += is lazy in bmake. This is different from FreeBSD, where it forces
> >expansion.
> >(2) The evaluation of j is lazy as well. That's why he sees the last
> >loop iteration.
>
> Well, it was true when I wrote the "for" code (more than 16 years
> ago!). I guess dsl re-wrote it, but the net effect is the same.
I don't have a source tree handy, and the change hasn't made it to cvsweb,
but the .for loop should:
1) evaluate the list of values when the .for list is parsed
2) process the loop body such that the value substituted for the loop
variable differs for each iteration.
xtos's version substituted the loop variable into the text prior to
the line being parsed - that gave some rather unexpected problems.
My rewrite left the expansion as a variable substitution by subtituting
${:U<value>} for the loop vsriable. This allows other modifiers that
use variables that are only defined later (or in commands) to work.
However it did cause some different quoting issues.
I didn't think of generating a unique name for the variable on each
iteration - and just substituting that value.
In fact this would only be needed for command lines - which have delayed
expansion. For control lines (processed during file parsing) the
value can just be put into the symbol table.
It would solve all the quoting issues.
David
--
David Laight: david%l8s.co.uk@localhost
Home |
Main Index |
Thread Index |
Old Index