Re: Named parameters in make?

[Lane Schwartz]

On Fri, Jun 10, 2011 at 7:20 AM, Oleksandr Gavenko <address@hidden>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