Re: [Rpm-ecosystem] Fwd: [Rpm-maint] Fixing macro scoping
On Fri, Feb 3, 2017 at 10:02 AM, Panu Matilainen
wrote:
> On 02/03/2017 04:54 PM, Panu Matilainen wrote:
>>
>> On 02/03/2017 03:26 PM, Pascal Terjan wrote:
>>>
>>> On 3 February 2017 at 12:14, Panu Matilainen
>>> wrote:
Stunned silence on rpm-maint, forwarding to rpm-ecosystem in hopes of a
larger and livelier audience...
- Panu -
Forwarded Message
Subject: [Rpm-maint] Fixing macro scoping
Date: Mon, 23 Jan 2017 12:30:21 +0200
From: Panu Matilainen
To: rpm-ma...@lists.rpm.org
Consider the following snippet, originating from
https://bugzilla.redhat.com/show_bug.cgi?id=552944:
%{!?foo: %define foo bar}
%define dofoo() true
echo 1: %{foo}
%dofoo
echo 2: %{foo}
I'd assume everybody agrees both %{foo}'s should evaluate to the same
value,
but that is not the case currently. Using a cli-variant of the above:
[pmatilai@sopuli rpm]$ rpm --define 'dofoo() true' --eval '%{!?foo:
%define
foo bar}' --eval '%foo' --eval '%dofoo' --eval '%foo'
warning: Macro %foo defined but not used within scope
bar
true
%foo
The flaw here is that rpm supposedly implements block level scoping for
macros (so in the above example, "foo" would only exist in the
{!?foo:...}
block), but doesn't actually enforce that, unless a parametric macro is
"called". Current rpm warns about it, but warnings or not this behavior
doesn't make the slightest sense.
The question is, what do you think %{foo} should evaluate to in this
case?
Fixing it to honor the strict "block scoping" concept is not hard,
now that
the scoping level is honored from Lua too (see
https://github.com/rpm-software-management/rpm/commit/1767bc4fd82bfacee622e698f9f0ae42c02126fa).
In this case the above reproducer would emit
%foo
true
%foo
Another option is slightly changing the whole scoping notion: parametric
macros require locally scoped macros for the automatic argument
macros like
%#, %* and %1 anyway (it's flawed too currently, see below). So
perhaps the
macro scoping should follow the current "call level", ie a macro defined
inside a parametric macro body is local to that macro, and everything
else
is global. In this case the reproducer would emit
bar
true
bar
>>>
>>>
>>> My first reaction was to prefer this one because '%{!?foo: %define foo
>>> bar} has been used in tens of thousands of packages and sort of worked
>>> "forever"
>>> But replacing define with global is not very hard so no strong opinion...
>>
>>
>> Me too, but no strong opinion either. Also I'm biased, because
>
>
> Oops. What that was supposed to say is that I'm biased because for years
> I've been explaining this "implemented before my time" block scoping thing
> to baffled packagers, so changing it now would feel at least somewhat
> awkward or something. But ultimately I just want a sane, clearly defined
> behavior, never mind my feelings :)
>
The thing is, I think you're absolutely right. I thought it was weird
too, but I've adapted to it. If we want to change it to a sane
behavior, it just needs to be clearly described so that that rely on
broken behavior are able to be fixed.
--
真実はいつも一つ！/ Always, there's only one truth!
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] Fwd: [Rpm-maint] Fixing macro scoping
On 02/03/2017 04:54 PM, Panu Matilainen wrote:
On 02/03/2017 03:26 PM, Pascal Terjan wrote:
On 3 February 2017 at 12:14, Panu Matilainen
wrote:
Stunned silence on rpm-maint, forwarding to rpm-ecosystem in hopes of a
larger and livelier audience...
- Panu -
Forwarded Message
Subject: [Rpm-maint] Fixing macro scoping
Date: Mon, 23 Jan 2017 12:30:21 +0200
From: Panu Matilainen
To: rpm-ma...@lists.rpm.org
Consider the following snippet, originating from
https://bugzilla.redhat.com/show_bug.cgi?id=552944:
%{!?foo: %define foo bar}
%define dofoo() true
echo 1: %{foo}
%dofoo
echo 2: %{foo}
I'd assume everybody agrees both %{foo}'s should evaluate to the same
value,
but that is not the case currently. Using a cli-variant of the above:
[pmatilai@sopuli rpm]$ rpm --define 'dofoo() true' --eval '%{!?foo:
%define
foo bar}' --eval '%foo' --eval '%dofoo' --eval '%foo'
warning: Macro %foo defined but not used within scope
bar
true
%foo
The flaw here is that rpm supposedly implements block level scoping for
macros (so in the above example, "foo" would only exist in the
{!?foo:...}
block), but doesn't actually enforce that, unless a parametric macro is
"called". Current rpm warns about it, but warnings or not this behavior
doesn't make the slightest sense.
The question is, what do you think %{foo} should evaluate to in this
case?
Fixing it to honor the strict "block scoping" concept is not hard,
now that
the scoping level is honored from Lua too (see
https://github.com/rpm-software-management/rpm/commit/1767bc4fd82bfacee622e698f9f0ae42c02126fa).
In this case the above reproducer would emit
%foo
true
%foo
Another option is slightly changing the whole scoping notion: parametric
macros require locally scoped macros for the automatic argument
macros like
%#, %* and %1 anyway (it's flawed too currently, see below). So
perhaps the
macro scoping should follow the current "call level", ie a macro defined
inside a parametric macro body is local to that macro, and everything
else
is global. In this case the reproducer would emit
bar
true
bar
My first reaction was to prefer this one because '%{!?foo: %define foo
bar} has been used in tens of thousands of packages and sort of worked
"forever"
But replacing define with global is not very hard so no strong opinion...
Me too, but no strong opinion either. Also I'm biased, because
Oops. What that was supposed to say is that I'm biased because for years
I've been explaining this "implemented before my time" block scoping
thing to baffled packagers, so changing it now would feel at least
somewhat awkward or something. But ultimately I just want a sane,
clearly defined behavior, never mind my feelings :)
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] Fwd: [Rpm-maint] Fixing macro scoping
On 02/03/2017 03:26 PM, Pascal Terjan wrote:
On 3 February 2017 at 12:14, Panu Matilainen wrote:
Stunned silence on rpm-maint, forwarding to rpm-ecosystem in hopes of a
larger and livelier audience...
- Panu -
Forwarded Message
Subject: [Rpm-maint] Fixing macro scoping
Date: Mon, 23 Jan 2017 12:30:21 +0200
From: Panu Matilainen
To: rpm-ma...@lists.rpm.org
Consider the following snippet, originating from
https://bugzilla.redhat.com/show_bug.cgi?id=552944:
%{!?foo: %define foo bar}
%define dofoo() true
echo 1: %{foo}
%dofoo
echo 2: %{foo}
I'd assume everybody agrees both %{foo}'s should evaluate to the same value,
but that is not the case currently. Using a cli-variant of the above:
[pmatilai@sopuli rpm]$ rpm --define 'dofoo() true' --eval '%{!?foo: %define
foo bar}' --eval '%foo' --eval '%dofoo' --eval '%foo'
warning: Macro %foo defined but not used within scope
bar
true
%foo
The flaw here is that rpm supposedly implements block level scoping for
macros (so in the above example, "foo" would only exist in the {!?foo:...}
block), but doesn't actually enforce that, unless a parametric macro is
"called". Current rpm warns about it, but warnings or not this behavior
doesn't make the slightest sense.
The question is, what do you think %{foo} should evaluate to in this case?
Fixing it to honor the strict "block scoping" concept is not hard, now that
the scoping level is honored from Lua too (see
https://github.com/rpm-software-management/rpm/commit/1767bc4fd82bfacee622e698f9f0ae42c02126fa).
In this case the above reproducer would emit
%foo
true
%foo
Another option is slightly changing the whole scoping notion: parametric
macros require locally scoped macros for the automatic argument macros like
%#, %* and %1 anyway (it's flawed too currently, see below). So perhaps the
macro scoping should follow the current "call level", ie a macro defined
inside a parametric macro body is local to that macro, and everything else
is global. In this case the reproducer would emit
bar
true
bar
My first reaction was to prefer this one because '%{!?foo: %define foo
bar} has been used in tens of thousands of packages and sort of worked
"forever"
But replacing define with global is not very hard so no strong opinion...
Me too, but no strong opinion either. Also I'm biased, because
I have implementations for both and also a personal opinion, but I'd like to
hear what others think.
The related flaw is whether locally scoped macros should be visible to
deeper nesting levels. Currently everything is, including those automatic
macros:
$ rpm --define '%bar() Bar %#: %{?1} %{?2}' --define '%foo() Foo %#: %{?1}
%{?2} %bar a' --eval '%foo 1 2'
Foo 2: 1 2 Bar 1: a 2
I'd consider this a bug, %2 should not be defined within %bar() since it did
not receive two arguments. So IMO the correct output in the above should be:
Foo 2: 1 2 Bar 1: a
Yes that's indeed very unexpected as I have always considered %n to be
referring to the parameters of current macros
All %n > %# should be cleared at the same time %# is set
Yup. Although not literally *cleared*, just made invisible in the inner
calls. You do want the original values to be there when returning from a
nested macro call.
But what about a macro manually %define'd within %foo() - should that be
visible in %bar()?
I would expect so
Interesting - I'd tend to think the contrary. I mean, considering
"normal" languages, local variables declared within a function are only
visible within that function. The exception to that would be nested
function definitions where the inner function can indeed access
everything its "parent" can, but this is conceptually different from
call-time scope.
Maybe an example would make it clearer. I would not expect this to work
in any remotely sane language [*]:
def bar():
b = 1
print(a + b)
def foo():
a = 1
bar()
...but this is a different story:
def foo():
a = 1
def bar():
b = 1
print(a + b)
bar()
[*] OTOH variables in Lua have global scope unless explicitly declared
local. A really annoying quirk in an otherwise nice and fun little language.
- Panu -
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] Fwd: [Rpm-maint] Fixing macro scoping
On Fri, Feb 3, 2017 at 9:21 AM, Panu Matilainen
wrote:
> On 02/03/2017 03:37 PM, Neal Gompa wrote:
>>
>> On Fri, Feb 3, 2017 at 7:35 AM, Panu Matilainen
>> wrote:
>>>
>>> On 02/03/2017 02:22 PM, Neal Gompa wrote:
>>> [...snip...]
Sorry if I sound stupid about this, but I've read this email at least
four times now, and I'm still not quite sure what you're trying to
describe...
>>>
>>>
>>>
>>> Right, quite possibly the question got lost in the rpm internals
>>> mumble-jungle.
>>>
>>> So forget the all the technical mumbling about scoping levels etc for
>>> now.
>>> What would you expect the following snippet to output (full reproducer
>>> spec
>>> is at https://bugzilla.redhat.com/show_bug.cgi?id=552944)?
>>>
>>> %{!?foo: %define foo bar}
>>> %define dofoo() true
>>> echo 1: %{foo}
>>> %dofoo
>>> echo 2: %{foo}
>>>
>>
>> I would expect that would expand each time. My expectation is that it
>> should evaluate and expand correctly on each invocation.
>>
>
> Well, define "correct". That is the question really :D
> What rpm currently does is obviously just totally broken, but there are at
> least two or three different, entirely plausible interpretations.
>
> I guess what you mean is you expect both echos to output "bar"?
>
> The other interpretation, which rpm takes (but the implementation is flawed)
> is that %{} forms a scope of its own, just like curly braces do in C, and
> %define'd macros are local to the scope they were defined in so the echo's
> would output literal "%{foo}" (or error out, but that's yet another
> side-track I'd rather not get on right now)
>
> I can easily live with either option assuming correct implementation, but
> I'm done encountering this stupid bug year after year after year when the
> next generation of packagers hits it. Lets just say that in a this kind of
> "minilanguage", I'd probably intuitively expect the less complex scoping.
> Meaning those echo's would evaluate to "bar".
>
Nothing in any documentation I've ever read indicates that %{} has
block scoping, so I would expect it to evaluate to "bar" each time.
That assumption seems to ring true with most packagers, given how I've
seen a lot of multi-line macros structured in blocks.
--
真実はいつも一つ！/ Always, there's only one truth!
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] Fwd: [Rpm-maint] Fixing macro scoping
On 02/03/2017 03:37 PM, Neal Gompa wrote:
On Fri, Feb 3, 2017 at 7:35 AM, Panu Matilainen
wrote:
On 02/03/2017 02:22 PM, Neal Gompa wrote:
[...snip...]
Sorry if I sound stupid about this, but I've read this email at least
four times now, and I'm still not quite sure what you're trying to
describe...
Right, quite possibly the question got lost in the rpm internals
mumble-jungle.
So forget the all the technical mumbling about scoping levels etc for now.
What would you expect the following snippet to output (full reproducer spec
is at https://bugzilla.redhat.com/show_bug.cgi?id=552944)?
%{!?foo: %define foo bar}
%define dofoo() true
echo 1: %{foo}
%dofoo
echo 2: %{foo}
I would expect that would expand each time. My expectation is that it
should evaluate and expand correctly on each invocation.
Well, define "correct". That is the question really :D
What rpm currently does is obviously just totally broken, but there are
at least two or three different, entirely plausible interpretations.
I guess what you mean is you expect both echos to output "bar"?
The other interpretation, which rpm takes (but the implementation is
flawed) is that %{} forms a scope of its own, just like curly braces do
in C, and %define'd macros are local to the scope they were defined in
so the echo's would output literal "%{foo}" (or error out, but that's
yet another side-track I'd rather not get on right now)
I can easily live with either option assuming correct implementation,
but I'm done encountering this stupid bug year after year after year
when the next generation of packagers hits it. Lets just say that in a
this kind of "minilanguage", I'd probably intuitively expect the less
complex scoping. Meaning those echo's would evaluate to "bar".
- Panu -
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] Fwd: [Rpm-maint] Fixing macro scoping
On Fri, Feb 3, 2017 at 7:35 AM, Panu Matilainen
wrote:
> On 02/03/2017 02:22 PM, Neal Gompa wrote:
> [...snip...]
>>
>>
>> Sorry if I sound stupid about this, but I've read this email at least
>> four times now, and I'm still not quite sure what you're trying to
>> describe...
>
>
> Right, quite possibly the question got lost in the rpm internals
> mumble-jungle.
>
> So forget the all the technical mumbling about scoping levels etc for now.
> What would you expect the following snippet to output (full reproducer spec
> is at https://bugzilla.redhat.com/show_bug.cgi?id=552944)?
>
> %{!?foo: %define foo bar}
> %define dofoo() true
> echo 1: %{foo}
> %dofoo
> echo 2: %{foo}
>
I would expect that would expand each time. My expectation is that it
should evaluate and expand correctly on each invocation.
--
真実はいつも一つ！/ Always, there's only one truth!
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] Fwd: [Rpm-maint] Fixing macro scoping
On 3 February 2017 at 12:14, Panu Matilainen wrote:
>
> Stunned silence on rpm-maint, forwarding to rpm-ecosystem in hopes of a
> larger and livelier audience...
>
> - Panu -
>
> Forwarded Message
> Subject: [Rpm-maint] Fixing macro scoping
> Date: Mon, 23 Jan 2017 12:30:21 +0200
> From: Panu Matilainen
> To: rpm-ma...@lists.rpm.org
>
>
> Consider the following snippet, originating from
> https://bugzilla.redhat.com/show_bug.cgi?id=552944:
>
> %{!?foo: %define foo bar}
> %define dofoo() true
> echo 1: %{foo}
> %dofoo
> echo 2: %{foo}
>
> I'd assume everybody agrees both %{foo}'s should evaluate to the same value,
> but that is not the case currently. Using a cli-variant of the above:
>
> [pmatilai@sopuli rpm]$ rpm --define 'dofoo() true' --eval '%{!?foo: %define
> foo bar}' --eval '%foo' --eval '%dofoo' --eval '%foo'
> warning: Macro %foo defined but not used within scope
>
> bar
> true
> %foo
>
> The flaw here is that rpm supposedly implements block level scoping for
> macros (so in the above example, "foo" would only exist in the {!?foo:...}
> block), but doesn't actually enforce that, unless a parametric macro is
> "called". Current rpm warns about it, but warnings or not this behavior
> doesn't make the slightest sense.
>
> The question is, what do you think %{foo} should evaluate to in this case?
>
> Fixing it to honor the strict "block scoping" concept is not hard, now that
> the scoping level is honored from Lua too (see
> https://github.com/rpm-software-management/rpm/commit/1767bc4fd82bfacee622e698f9f0ae42c02126fa).
> In this case the above reproducer would emit
>
> %foo
> true
> %foo
>
> Another option is slightly changing the whole scoping notion: parametric
> macros require locally scoped macros for the automatic argument macros like
> %#, %* and %1 anyway (it's flawed too currently, see below). So perhaps the
> macro scoping should follow the current "call level", ie a macro defined
> inside a parametric macro body is local to that macro, and everything else
> is global. In this case the reproducer would emit
> bar
> true
> bar
My first reaction was to prefer this one because '%{!?foo: %define foo
bar} has been used in tens of thousands of packages and sort of worked
"forever"
But replacing define with global is not very hard so no strong opinion...
> I have implementations for both and also a personal opinion, but I'd like to
> hear what others think.
>
> The related flaw is whether locally scoped macros should be visible to
> deeper nesting levels. Currently everything is, including those automatic
> macros:
>
> $ rpm --define '%bar() Bar %#: %{?1} %{?2}' --define '%foo() Foo %#: %{?1}
> %{?2} %bar a' --eval '%foo 1 2'
> Foo 2: 1 2 Bar 1: a 2
>
> I'd consider this a bug, %2 should not be defined within %bar() since it did
> not receive two arguments. So IMO the correct output in the above should be:
> Foo 2: 1 2 Bar 1: a
Yes that's indeed very unexpected as I have always considered %n to be
referring to the parameters of current macros
All %n > %# should be cleared at the same time %# is set
> But what about a macro manually %define'd within %foo() - should that be
> visible in %bar()?
I would expect so
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] Fwd: [Rpm-maint] Fixing macro scoping
On 02/03/2017 02:22 PM, Neal Gompa wrote:
[...snip...]
Sorry if I sound stupid about this, but I've read this email at least
four times now, and I'm still not quite sure what you're trying to
describe...
Right, quite possibly the question got lost in the rpm internals
mumble-jungle.
So forget the all the technical mumbling about scoping levels etc for
now. What would you expect the following snippet to output (full
reproducer spec is at https://bugzilla.redhat.com/show_bug.cgi?id=552944)?
%{!?foo: %define foo bar}
%define dofoo() true
echo 1: %{foo}
%dofoo
echo 2: %{foo}
- Panu -
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] Fwd: [Rpm-maint] Fixing macro scoping
On Fri, Feb 3, 2017 at 7:14 AM, Panu Matilainen
wrote:
>
> Stunned silence on rpm-maint, forwarding to rpm-ecosystem in hopes of a
> larger and livelier audience...
>
> - Panu -
>
>
> Forwarded Message
> Subject: [Rpm-maint] Fixing macro scoping
> Date: Mon, 23 Jan 2017 12:30:21 +0200
> From: Panu Matilainen
> To: rpm-ma...@lists.rpm.org
>
>
> Consider the following snippet, originating from
> https://bugzilla.redhat.com/show_bug.cgi?id=552944:
>
> %{!?foo: %define foo bar}
> %define dofoo() true
> echo 1: %{foo}
> %dofoo
> echo 2: %{foo}
>
> I'd assume everybody agrees both %{foo}'s should evaluate to the same value,
> but that is not the case currently. Using a cli-variant of the above:
>
> [pmatilai@sopuli rpm]$ rpm --define 'dofoo() true' --eval '%{!?foo: %define
> foo bar}' --eval '%foo' --eval '%dofoo' --eval '%foo'
> warning: Macro %foo defined but not used within scope
>
> bar
> true
> %foo
>
> The flaw here is that rpm supposedly implements block level scoping for
> macros (so in the above example, "foo" would only exist in the {!?foo:...}
> block), but doesn't actually enforce that, unless a parametric macro is
> "called". Current rpm warns about it, but warnings or not this behavior
> doesn't make the slightest sense.
>
> The question is, what do you think %{foo} should evaluate to in this case?
>
> Fixing it to honor the strict "block scoping" concept is not hard, now that
> the scoping level is honored from Lua too (see
> https://github.com/rpm-software-management/rpm/commit/1767bc4fd82bfacee622e698f9f0ae42c02126fa).
> In this case the above reproducer would emit
>
> %foo
> true
> %foo
>
> Another option is slightly changing the whole scoping notion: parametric
> macros require locally scoped macros for the automatic argument macros like
> %#, %* and %1 anyway (it's flawed too currently, see below). So perhaps the
> macro scoping should follow the current "call level", ie a macro defined
> inside a parametric macro body is local to that macro, and everything else
> is global. In this case the reproducer would emit
>
> bar
> true
> bar
>
> I have implementations for both and also a personal opinion, but I'd like to
> hear what others think.
>
> The related flaw is whether locally scoped macros should be visible to
> deeper nesting levels. Currently everything is, including those automatic
> macros:
>
> $ rpm --define '%bar() Bar %#: %{?1} %{?2}' --define '%foo() Foo %#: %{?1}
> %{?2} %bar a' --eval '%foo 1 2'
> Foo 2: 1 2 Bar 1: a 2
>
> I'd consider this a bug, %2 should not be defined within %bar() since it did
> not receive two arguments. So IMO the correct output in the above should be:
> Foo 2: 1 2 Bar 1: a
>
> But what about a macro manually %define'd within %foo() - should that be
> visible in %bar()?
>
Sorry if I sound stupid about this, but I've read this email at least
four times now, and I'm still not quite sure what you're trying to
describe...
--
真実はいつも一つ！/ Always, there's only one truth!
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
[Rpm-ecosystem] Fwd: [Rpm-maint] Fixing macro scoping
Stunned silence on rpm-maint, forwarding to rpm-ecosystem in hopes of a
larger and livelier audience...
- Panu -
Forwarded Message
Subject: [Rpm-maint] Fixing macro scoping
Date: Mon, 23 Jan 2017 12:30:21 +0200
From: Panu Matilainen
To: rpm-ma...@lists.rpm.org
Consider the following snippet, originating from
https://bugzilla.redhat.com/show_bug.cgi?id=552944:
%{!?foo: %define foo bar}
%define dofoo() true
echo 1: %{foo}
%dofoo
echo 2: %{foo}
I'd assume everybody agrees both %{foo}'s should evaluate to the same
value, but that is not the case currently. Using a cli-variant of the above:
[pmatilai@sopuli rpm]$ rpm --define 'dofoo() true' --eval '%{!?foo:
%define foo bar}' --eval '%foo' --eval '%dofoo' --eval '%foo'
warning: Macro %foo defined but not used within scope
bar
true
%foo
The flaw here is that rpm supposedly implements block level scoping for
macros (so in the above example, "foo" would only exist in the
{!?foo:...} block), but doesn't actually enforce that, unless a
parametric macro is "called". Current rpm warns about it, but warnings
or not this behavior doesn't make the slightest sense.
The question is, what do you think %{foo} should evaluate to in this case?
Fixing it to honor the strict "block scoping" concept is not hard, now
that the scoping level is honored from Lua too (see
https://github.com/rpm-software-management/rpm/commit/1767bc4fd82bfacee622e698f9f0ae42c02126fa).
In this case the above reproducer would emit
%foo
true
%foo
Another option is slightly changing the whole scoping notion: parametric
macros require locally scoped macros for the automatic argument macros
like %#, %* and %1 anyway (it's flawed too currently, see below). So
perhaps the macro scoping should follow the current "call level", ie a
macro defined inside a parametric macro body is local to that macro, and
everything else is global. In this case the reproducer would emit
bar
true
bar
I have implementations for both and also a personal opinion, but I'd
like to hear what others think.
The related flaw is whether locally scoped macros should be visible to
deeper nesting levels. Currently everything is, including those
automatic macros:
$ rpm --define '%bar() Bar %#: %{?1} %{?2}' --define '%foo() Foo %#:
%{?1} %{?2} %bar a' --eval '%foo 1 2'
Foo 2: 1 2 Bar 1: a 2
I'd consider this a bug, %2 should not be defined within %bar() since it
did not receive two arguments. So IMO the correct output in the above
should be:
Foo 2: 1 2 Bar 1: a
But what about a macro manually %define'd within %foo() - should that be
visible in %bar()?
- Panu -
___
Rpm-maint mailing list
rpm-ma...@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
