On Fri, Jun 10, 2011 at 11:19 AM, Philip Guenther <[email protected]>wrote:
> On Fri, Jun 10, 2011 at 6:09 AM, Lane Schwartz <[email protected]> wrote: > > A major reason why the resulting code looks cryptic is because of the $1, > > $2, $3... variable names for parameters. If there were some way to name > > these parameters, the resulting code would be better documented and more > > readable. > ... > > Here's a (slightly simplified) use case that comes from one of my > Makefiles: > > > > TMs:=$(wildcard tm-*) > > LMs:=$(wildcard lm-*) > > DEVs:=$(wildcard dev-*) > > > > define OPTIMIZE > > > > $1.$2.$3/optimize.cfg: $1/fragment.cfg $2/fragment.cfg $3/fragment.cfg | > $1.$2.$3 > > cat $$^ > $$@ > > > > $1.$2.$3: > > mkdir -p $$@ > > > > endef > > > > # Dynamically construct new targets > > $(foreach TM,${TMs},\ > > $(foreach LM,${LMs},\ > > $(foreach DEV,${DEVs},\ > > $(eval $(call OPTIMIZE,${TM},${LM},${DEV}))\ > > )\ > > )\ > > ) > > > > > > Named parameters would in this case mean that I could use names like > ${TM} > > instead of $1, ${LM} instead of $2, and ${DEV} instead of $3, making the > > define block more readable. > > You *can* use those names, Right Now! You're setting TM, LM, and DEV > right now to exactly the value you want. You don't *have* to use $1, > $2, and $3. Indeed, if you don't then you don't need to use $(call) > here at all; that's (almost) all that $(call) does, compared to simply > expanding the named variable. Compare: > > ----- > TMs:=$(wildcard tm-*) > LMs:=$(wildcard lm-*) > DEVs:=$(wildcard dev-*) > > define OPTIMIZE > > all: ${TM}.${LM}.${DEV}/optimize.cfg > ${TM}.${LM}.${DEV}/optimize.cfg: ${TM}/fragment.cfg ${LM}/fragment.cfg \ > ${DEV}/fragment.cfg | ${TM}.${LM}.${DEV} > cat $$^ > $$@ > > ${TM}.${LM}.${DEV}: > mkdir -p $$@ > > endef > > # Dynamically construct new targets > $(foreach TM,${TMs},\ > $(foreach LM,${LMs},\ > $(foreach DEV,${DEVs},\ > $(eval ${OPTIMIZE})\ > )\ > )\ > ) > ---- > Wow. This is incredible! Thank you, Philip!!! I consider myself to be a pretty savvy make user, but I did not know about this feature. Paul, this needs to be documented. The sections in the manual on call and eval don't talk to this point at all. It seems that an example like this should go in the eval section. I think it's very interesting that within the define block, using the origin function on the parameters (TM, LM, DEV) reports that they are automatic variables. This should also be documented (that the var of a foreach is considered to be an automatic variable while it's in scope). Paul, if you want a volunteer for adding this info to the manual, let me know. :) Cheers, Lane _______________________________________________ Help-make mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-make
