Calling a parameterized macro from another one

[Panu Matilainen]

On 10/08/2013 07:48 PM, Bob Bell wrote:
> Is no one able to help with this issue? :(

Sorry I thought I already replied to this (I do remember starting a 
reply) but obviously not...

>
> On Mon, Sep 09, 2013 at 03:25:05PM -0400, Bob Bell wrote:
>> I've been bumping up RPM macro/spec sophistication recently, and one
>> thing I'm trying to do is to call one parameterized RPM macro from
>> another parameterized RPM macro.  I'm seeing some behavior that's ...
>> less than helpful.
>>
>> As a real quick summary, here's what I'm seeing:
>>  1. When I call the second macro, %# and %* are set, as are the
>> positional parameters (%1, etc.) for anything that's been set, but
>> positional parameters that haven't been passed in remain set from the
>> previous macro invocation (i.e., the "parent" invocation)
>>  2. When I pass parameters via named flags to the second macro, any
>> existing flags remain set.  This is true even if the second macro
>> takes the same parameters, but I don't pass them, which is
>> particularly troubling.
>>
>> This makes it really hard (almost impossible?) to determine what
>> parameters were actually pass to the second macro.  For example,
>>  1. If the second macro can take, say, either one or two parameters, I
>> cannot reliably use %{?2} to check if a second parameters has been
>> passed.  I need to check to see if %# == 2 first, because %2 might be
>> set from another macro that's been invoked.
>>  2. If the first and second macro both take a flag (say, "-f"), but
>> the      same flag isn't passed as a parameter to the second macro,
>> it's pretty much impossible to tell, because %{-f} (and its variants)
>> will still be set from when the first macro was invoked.
>>
>> Can someone clarify what the behavior SHOULD be?  Is this a bug?
>> Should I be doing things differently?

Lets just say the above description matches what I would expect from the 
current implementation. That doesn't make the behavior any more sensible 
of course.

>> Here's my test ~/.rpmmacros file that I'm using to explore RPM's
>> functionality:
>> %bar(x:y:z:) \
>> %{lua:io.stderr:write(rpm.expand("%#") .. " arg(s) to " ..
>> rpm.expand("%0") .. " = " .. rpm.expand("%*") .. "\\n")} \
>> %{lua:io.stderr:write("1 == " .. rpm.expand("%1") .. "\\n")} \
>> %{lua:io.stderr:write("2 == " .. rpm.expand("%2") .. "\\n")} \
>> %{lua:io.stderr:write("-x == " .. rpm.expand("%{-x}") .. "\\n")} \
>> %{lua:io.stderr:write("-x* == " .. rpm.expand("%{-x*}") .. "\\n")} \
>> %{lua:io.stderr:write("-y == " .. rpm.expand("%{-y}") .. "\\n")} \
>> %{lua:io.stderr:write("-y* == " .. rpm.expand("%{-y*}") .. "\\n")} \
>> %{lua:io.stderr:write("-z == " .. rpm.expand("%{-z}") .. "\\n")} \
>> %{lua:io.stderr:write("-z* == " .. rpm.expand("%{-z*}") .. "\\n")}
>> %foo(x:y:) \
>> %{lua:io.stderr:write(rpm.expand("%#") .. " arg(s) to " ..
>> rpm.expand("%0") .. " = " .. rpm.expand("%*") .. "\\n")} \
>> %{lua:io.stderr:write("1 == " .. rpm.expand("%1") .. "\\n")} \
>> %{lua:io.stderr:write("2 == " .. rpm.expand("%2") .. "\\n")} \
>> %{lua:io.stderr:write("-x == " .. rpm.expand("%{-x}") .. "\\n")} \
>> %{lua:io.stderr:write("-x* == " .. rpm.expand("%{-x*}") .. "\\n")} \
>> %{lua:io.stderr:write("-y == " .. rpm.expand("%{-y}") .. "\\n")} \
>> %{lua:io.stderr:write("-y* == " .. rpm.expand("%{-y*}") .. "\\n")} \
>> %{expand:%%{bar %{-x} %{-y:-z} %{-y*} bararg}}
>>
>> And here's the results I've seen that lead to my conclusions:
>> # rpm --eval '%{foo -x A -y B fooarg1 fooarg2}' >/dev/null
>> 2 arg(s) to foo = fooarg1 fooarg2
>> 1 == fooarg1
>> 2 == fooarg2
>> -x == -x A
>> -x* == A
>> -y == -y B
>> -y* == B
>> 1 arg(s) to bar = bararg
>> 1 == bararg
>> 2 == fooarg2
>> -x == -x A
>> -x* == A
>> -y == -y B
>> -y* == B
>> -z == -z B
>> -z* == B
>>
>> My primary test bed has been SUSE Linux Enterprise Server 11 SP2,
>> running rpm 4.4.2.3 (with SUSE patches, no doubt).  I'm confirmed the
>> same behavior on an Ubuntu machine with rpm 4.9.1.1.

As Robert already pointed out, with existing releases your best hope is 
to use different flags to disambiguate & use %# to determine number of 
arguments. Or try to arrange the macros differently to avoid the issue.

Thanks for the detailed report and reproducer though, one of these days 
I might take a look at what it would take to make the local arg macros 
scope correctly.

	- Panu -

>> Thanks in advance for your assistance,
>> Bob
>>
>> P.S. I'm not currently subscribed to this mailing list, so please
>> include me on any replies.
> _______________________________________________
> Rpm-list mailing list
> Rpm-list at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-list