Calling a parameterized macro from another one

[Robert Flum]

Hi Bob,

  My reading of the syntax is that you have to use the form %# to determine
how many parameters are passed, just as you describe.  That's the way to
tell which positional parameters have been passed.

  I suggest getting around the second issue by using differently-named
flags to the second macro, e.g.: %bar(q:r:s:).

  Rob


On Tue, Oct 8, 2013 at 12:48 PM, Bob Bell <b_rpmlist at thebellsplace.com>wrote:

> Is no one able to help with this issue? :(
>
> 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?
>>
>> 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.
>>
>> 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<http://lists.rpm.org/mailman/listinfo/rpm-list>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-list/attachments/20131014/461cab77/attachment.html>