Eddy,
thanks very much for the reply. and, for the hints (on better use of
make functions).
>> something:
>> @touch ${NEWIN}
> It is generally good to let make know what files a rule creates, rather
> than creating files as a side-effect of making a phony target.
i guess this is the key. in my actual application, the "something" rule
is a "git pull", which updates the file system with files about which my
Makefile has no knowledge (other than that, e.g., they end in ".input").
i guess the "right" solution for me is to do a sub-make at that point,
to make the files in the pattern rules based on the then-current
contents of the file system.
i don't know if it would be worth issuing a warning that a variable used
in determining the dependencies at make startup had changed its value.
i guess it's not even clear when one would re-expand such variables to
check. maybe at the end of a run (success or failure?) one might
re-expand variables and re-build the dependency graph, and then compare
the second graph with the original, reporting any discrepancies. but,
again, i've no idea if this issue comes up enough to make that effort
worth the while (or, even, whether one should expect such an approach to
even work, after all the random makefile processing up to that point).
again, thanks for the reply. and, the tool!
cheers, Greg
