On Fri, Jun 10, 2011 at 7:20 AM, Oleksandr Gavenko <[email protected]>wrote:
> On 10.06.2011 1:16, Peng Yu wrote: > > >> Hi, >> >> I think that there is probably no way to support named parameters in >> make ($(eval $(call ...))). But I want double-check in case there is >> some walkaround to emulate named parameters. Could anybody let me >> know? >> >> http://en.wikipedia.org/wiki/Named_parameter >> >> >> > Why you need named parameters in GNU Make? > > For documentation purpose? > > I don't often use eval/call in GNU Make. And only as "advanced" macros. > Resulted code look some cryptic so I try avoid them. > > For some advanced tasks, there's no solution that I've found other than eval/call. 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. > You can emulate C like structure in GNU Make by double substitution: > > my_str = "hello" > my_str_len = 4 > > your_str = "bye" > your_str_len = 3 > > data = my > $(info String is: $($(data)_str) and $($(data)_str_len) long.) > data = your > $(info String is: $($(data)_str) and $($(data)_str_len) long.) > > Is this useful for you? > > Thanks for the suggestions. There are certainly times when your solution is helpful. Maybe I'm missing something, but I don't see how that technique could be used to emulate named parameters in define blocks that are used with eval/call. 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. Ultimately, the reason for using the eval/call block in my case is a need for more powerful pattern rules than using % provides. Cheers, Lane _______________________________________________ Help-make mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-make
