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

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR bin/60850; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/60850: Make could do with a syntax for immediate var expansion
Date: Wed, 07 Oct 2026 05:36:43 +0700

     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