Renamed to %{macrobody:..} and argument expanded now.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I can live with macrobody, a little bit of name-spacing never hurt anybody.
In the meanwhile, I'm starting to think it does need to expand its argument
like everything else, this is too limiting. Ie it'd still take a macro name as
an argument, but that the name can come from a macro instead of
I'd prefer if we named this %macrobody, so that there's less chance that it
clashes with somebody else's use of %body.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
pmatilai commented on this pull request.
> @@ -72,6 +72,7 @@ to perform useful operations. The current list is
%define ... define a macro
%undefine ... undefine a macro
%global ... define a macro whose body is available in global context
+ %{body:...}
voxik commented on this pull request.
> @@ -72,6 +72,7 @@ to perform useful operations. The current list is
%define ... define a macro
%undefine ... undefine a macro
%global ... define a macro whose body is available in global context
+ %{body:...}
Some open questions:
- Should the argument be expanded first, like doFoo() does? Using the literal
value has its pros but I guess its cons too.
- Is raising an error on undefined macro a reasonable thing to do? If not, what
should it do on undefined macros?
I was also tempted to add %{opts:...}
Fixes: #582
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1064
-- Commit Summary --
* Implement %{body:...} built-in for retrieving the literal macro body
-- File Changes --
M doc/manual/macros (1)
M
