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

Vít Ondruch vondruch at redhat.com
Mon Feb 20 08:46:34 UTC 2017



Dne 18.2.2017 v 13:40 Neal Gompa napsal(a):
> On Tue, Feb 7, 2017 at 3:46 AM, Panu Matilainen
> <pmatilai at laiskiainen.org> wrote:
>> 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"...
>>
> Laid out like that, I think "implement a proper local stack" is the
> right way to go...
>
>
>

I agree.


V.


More information about the Rpm-ecosystem mailing list