[Rpm-ecosystem] Fwd: [Rpm-maint] Fixing macro scoping

Panu Matilainen pmatilai at laiskiainen.org
Tue Feb 7 08:46:35 UTC 2017


On 02/07/2017 10:04 AM, Vít Ondruch wrote:
>
>
> Dne 6.2.2017 v 19:43 Panu Matilainen napsal(a):
>> On 02/06/2017 06:51 PM, Vít Ondruch wrote:
>>>
>>>
>>> Dne 6.2.2017 v 16:00 Panu Matilainen napsal(a):
>>>>
>>>> One open question I have is what to do with %undefine's: currently rpm
>>>> allows %undefining anything from any scope, and that is at odds with
>>>> any attempt to rationalize and formalize the scoping to something
>>>> actually comprehensible. A simple approach is that you can only
>>>> undefine something from your local scope or the global scope. But what
>>>> if there's something by the same name in between?
>>>>
>>>
>>> What is wrong with this? You always undefine the value from the top of
>>> the stack ...
>>
>> What do you mean by "this" - the current behavior or the alleged
>> scoping aware new version?
>>
>> The current behavior indeed just removes from top of the stack with no
>> consideration as to who defined the macro and where. And this in a
>> system that makes claims about scoping...
>>
>
> Right, now I see ... but then I don't understand what you meant by "But
> what if there's something by the same name in between?"

Right, maybe an example will make it clearer. Indenting and missing 
line-continuation characters are supposed to be for readers benefit:

---
%define foo 1

%define dofoo()
     %define foo foo
     %undefine foo
     %undefine foo

%define dobar()
     %define foo bar
     %dofoo
     echo %foo

%dobar
---

So dobar() defines a local %foo which shadows the global %foo. Then it 
calls dofoo() which creates its own local %foo, and then %undefines it 
twice. What is supposed to happen in this case?

The way I see it, if we're supposed to have some sort of meaningful 
scopes, the undefines in dofoo() cannot possibly affect the definition 
of foo in dobar(). So does the second undefine affect the globally 
defined foo? That's one possible interpretation, but this is a problem 
with the rpm implementation of things as the macros stack globally, so 
instead of popping the macro at top of stack, it'd be popping it from 
bottom of it because there's the dobar() definition in between.

Without violating the principles of the global macro stack, the only 
possible interpretation I see is declaring the second undefine a no-op 
(as in try to undefine a non-existent macro). Whether that is sensible 
at all is an entirely different question - it almost certainly is not.

It's also quite possible the only sane answer here is "implement a 
proper local stack then"...

	- Panu -

	- Panu -


More information about the Rpm-ecosystem mailing list