Re: Calling a parameterized macro from another one

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list

_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list

[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux