Re: bin/60850: Make could do with a syntax for immediate var expansion

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 6 Oct 2026 12:59:08 -0400
    From:        Rob Whitlock <rwhitlock22%gmail.com@localhost>
    Message-ID:  <5AECF203-D2A4-4A2E-9E8E-67117E1915BE%gmail.com@localhost>

  | I would want to know whether my earlier example satisfies your need.

It sort of does, and it is approximately what I had done (before I submitted
the PR) to solve the build problem we were having.   It just isn't good enough.

  | If it provides the needed functionality then I don't see how a new
  | variable modifier is needed.

New syntax I requested, whether that is a variable modifier, or some
other way (another possibility would be to add +:= as a new assignment
operator, which would expand its string like := does, and then append
the result to the named variable, just like += does - but without
needing the intermediate variable, to use on an := line, followed by
its use on the += line, as while at first glance those intermediate
variables seem to be used for just the two lines, they're not, once
created, its value needs to remain stable until the actual variable
we're assigning to gets used.

The problem with the actual example you used, where the intermediate
variable was "MYPARSEDIR" is exactly the same as the one in RVP's
example which used _ as the variable - those are so obvious, that
they would be used all the time.

The problem occurs in usage like

	.include <subdir/Makefile.inc>
	.include <arch/${ARCH}/Makefile.inc>
	.if expression-to-test-some-option
	.include <option-dir/Makefile.inc>
	.endif

(sometimes with many .include lines).

Each Makefile.inc wants to (needs to)

	CPPFLAGS+= -I ${.PARSEDIR}

to get the eventual cc command to search for .h files in the
relevant directory (particularly the middle one where there
will be architecture dependent include files for many different
architectures and the right set need to be found).

(There are likely to be more vars set in a similar way, SRCS to
list all the files that need compiling is also likely, but 1 or
a dozen, the same mechanism is needed for each ... they do all just
need one intermediate variable however, not one for each.)

Please ignore whatever you think about this actual example, and
how it would be better done like something else, that is not the
point here.

If your proposed method was used, just as you wrote it, in each
of those files, what we would end up with is

	CPPFLAGS= ..... -I /whatever/option-dir -I /whatever/option-dir \
		-I /whatever/option-dir ....

as by the time it is expanded, MYPARSEDIR would be whatever value was
assigned to it most recently, which in this case, assuming the expression
returned "true" would be the ${.PARSEDIR} value for the option-dir.

What I actually did, which was similar to your sugegstion, was to invent
a new, unlikely to be used, typically quite long, new variable name for
each instance (each Makefile.inc), so that (hopefully) nothing else anywhere
would be changing them.   That's unreliable - relies more on luck than
anything else (though it turned out, that for now at least, I was lucky
enough to invent new var names that didn't conflict with anything else).
That is, "for now" - someone might just happen to pick one of the same
names to use, for a similar, or quite different, purpose, any time in
the future - these are just "junk" names, they aren't ever going to be
documented anywhere.

Hence the suggestion for a new mechanism, that doesn't require new
variables (or not any new long term variables) to be invented.

uwe@'s suggestion to use a dummy .for loop, and variable, which (I had
no idea) always gets expanded immediately when referenced would work,
but is just such a hack, and so incomprehensible, that there really
should be some better way.

Simply making ${.PARSEDIR} (and other make supplied variables like it,
which have only temporary values) expand immediately upon reference, just
like for variables apparently do, would solve the actual problem experienced
trivially - but a more general mechanism seems, to me, as if it would be
a better idea.   What mechanism is for people who actually understand make
to determine which would be best -- that is certainly not me - hence the
"expression-to-test-some-option" above, as I didn't want to attempt to
write something real, and have this PR devolve into discussion of how that
expression should have been written, or what other way would be better,
as I have seen happen (not perhaps for this precise example) before.

kre