In GNU make, it's unclear from the manual (but very clear from looking at the code) whether the params to user defined functions are simply eval'ed or recursively eval'ed.
They are, in fact, simply evaulated. I believe that having them be recursively evaluated is more useful. I want to do iteration within user defined functions. And the param to be supplied as an argument has recursively evaluated variables that will vary as the iteration variable changes. [I actually currently have the iteration outside of any user defined functions and it works just fine. But, I'm making a change where depending upon a selection early in the makefile, the ``higher level'' variables will be defined differently and the iteration will change between being a single iteration versus being a double iteration.] >From a perusal of the mailing list archives, I take it that there was some concern that changing how the params to user defined functions are evaluated might not be backwards compatible. With a one character change to func_call, I can get my stripped down example to work; without it, I have yet to find the right incantation. So I'm, of course, in favor of such a change. How's this for a proposal: . a new phony target (just like .SECONDEXPANSION), called .RECURSIVEFUNCTIONPARAMS or something equally clueful. If the phony target is not seen, you get the old behavior. Should therefore be totally backwards compatible. . a check in read.c (just after the check for .SECONDEXPANSION) that sets an appropriate variable. . a change to func_call to pass 0 or 1 to define_variable depending on whether the aforementioned variable is 0 or 1. . an addition to the features list so that a makefile can check to see if the make being used supports the feature and can error out if not. . a little verbiage for the make.texi file so that it's documented. If the above stands a chance of being accepted, I might implement it. What should the phony target name be? What should the feature name be? NOTE: EMC does not currently have a copyright assignment on file for GNU make; but we do have one on file for GCC, BINUTILS, and GDB. I would assume (hopefully not too naively) that adding MAKE to the list would be straightforward for the lawyers. If there is interest, I can start the process. _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
