[A-a-p-user] Re[2]: Scopes (long)

[Steve H. <ho...@ca...>]

Hello Bram,

Wednesday, January 15, 2003, 11:38:23 AM, you wrote:


BM> Steve Howe wrote:

BM> The above is contradictory.  Here is the example again I gave in a
BM> previous message:

BM>          recipe main.aap:

BM>                  ABC = something
BM>                  :child foo.aap
BM>                  :update foo.x
     
BM>          recipe foo.aap:

BM>                  foo.x : foo.y
BM>                          :print $ABC

BM> - If the build commands for foo.x are considered like they are in a
BM>   function, they would not be able to access the ABC variable, since it
BM>   only exists in another recipe: main.aap.
BM> - If the build commands use the global scope and can access the ABC
BM>   variable there can't be a local variable ABC with a different value
BM>   (without additional scope specs).
My original idea was that all recipes (main and children) share a
common "global" scope. 

If that is true, ABC will be passed to all child recipes and ABC will
be available.

However, that will lead us to another trouble situation, where a child
recipe could mess the main recipe's variables. I'll discuss this
further below.


[...]
(I have omitted Bram's original proposal to keep the message shorter)

BM> Sorry for the long text, hope you are still with me.
Oh, of course I am you and I'm very interested in the subject.
I agree with your points and you have raised several good case
situations.

I have an enhanced proposal that builds on your ideas and concerns but
I'm not sure if you'll like it.

After reading it your message, I came to the conclusion that in fact
we have (or should have, in implementation) 3 scopes: "global",
"recipe" and "local" (the names could probably be others I guess):

Global: scope available to all recipes.
Module: scope available to the current recipe.
Local: scope available to the current build.

The precedence of scopes would be this:
local->module->global (local overrides module which overrides global)

To specify which scope is to be used, we could qualify the scope using
statements such as:

local.myvar    (refers to myvar from the [local] scope)
recipe.myvar   (refers to myvar from the [recipe] scope)
global.myvar   (refers to myvar from the [global] scope)

When referring to a variable without scope, the [local] scope should
be looked for; if the variable name is not found, the [recipe] scope;
if not found, the [global] scope; if not found, then an Exception
should be raised.

If a variable is assigned without any scope, and is outside a build
command, it will belong to [module]; if used in a build command, it
will belong to [local]. Only variables declared as [global] (i.e.
global.myvar) should be inherited by child recipes.

Of course the CFLAGS, CC, and other important/default variables that
are global in nature should be declared by A-A-P as being in the
global context of course. This would make them available to child
recipes too, and even if them are redefined in a child recipe:

CFLAGS = -O2

... they would belong to [module] and this wouldn't modify the global
variable. But if the global variable needed to be modified, then
something as

global.CFLAGS = -O4

could be used.

The :global, :local and :export commands could even be deprecated by
introduction this scheme.

This would avoid the :export problems, since the exact scope to export
to is specified. Child recipes could change global variables or have
their own in their [recipe] or [local] scopes, whose would override
the [global] scope. It would avoid the scopes conflicts but keep
flexibility.

I think this covers all situations... doesn't it ? Can you think of
some situation it wouldn't cover ? Also it specifies a clear way of
declaring variables in any scope, and also a clear way of referring to
any scope.

Any comments ?

------------- 
Best regards,
 Steve Howe                           mailto:ho...@ca...