Re: CVS commit: src/usr.bin/make

[Roland Illig <roland.illig%gmx.de@localhost>]

Am 09.01.2022 um 23:04 schrieb Joerg Sonnenberger:
> On Fri, Jan 07, 2022 at 08:04:49PM +0000, Roland Illig wrote:
> > Module Name:	src
> > Committed By:	rillig
> > Date:		Fri Jan  7 20:04:49 UTC 2022
> >
> > Modified Files:
> > 	src/usr.bin/make: for.c
> >
> > Log Message:
> > make: use simpler code for handling .for loops
>
> This seems backwards to me. For simpler logic I would expect computing
> the var length first and then skipping variables that don't have the
> same length, falling back to memcmp otherwise.

As it is now, the body of the .for loop is a simple string.  As such,
there are no markers where variables start and end, therefore "the same
length" is not known in advance.

It would be possible to parse the body of the .for loop first, so that
each part is either:

* a plain string that is copied verbatim
* '$' + a one-character variable name
* '$' + (brace or parenthesis) + variable name

After preparing the .for loop in this way, the lengths of the variable
names in the body would be known, and it would make sense to match them
with the variable names from the .for loop.  This would have to be done
only once though since the names of the iteration variables don't
change.  Then again, I don't see why it would be beneficial to compute
the length of a variable name in advance.  If I missed a point here,
please tell me. :)

It's definitely an interesting idea to avoid parsing the loop body on
each iteration.  I will experiment on that idea to see whether it makes
a noticeable difference.

Since everything else in makefiles is parsed and evaluated only once, I
don't see an immediate benefit of first parsing constructs other than
.for loops into data structures and then evaluating them.

Another possible optimization is multiple-inclusion guards.  That's
completely independent though.