Proposed change to default variable scoping

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-03-25 13:00:55

Here's the tail of a conversation Rene and I have been having about the
default variable scoping in Boost.Jam. Right now we have three types of
variables:

local, global, and module-local. The latter are not used in Boost.Build
v1 (since we don't use modules -- or rather, we only use the global
module). Rene and I are proposing that we change the semantics of
variables declared without "local" so that they are local to the current
module. Hey, that would also get rid of the need for the "module local"
declaration syntax! Hooray!

If you have objections to this move, now is the time to speak up!

-Dave

----- Original Message -----
From: "Rene Rivera" <grafik666_at_[hidden]>
To: "David Abrahams" <david.abrahams_at_[hidden]>
Sent: Monday, March 25, 2002 1:01 PM
Subject: Re: Still failing with Linux/GCC

> On 2002-03-25 at 12:35 PM, david.abrahams_at_[hidden] (David Abrahams)
wrote:
>
> >Let me get this straight: you want variables to default to local, or
to
> >module local?
>
> module local.
>
> >I hate that Perforce made variables global by default, but
> >since they did I don't think a construct which flips the default
meaning
> >to scope-local would be appropriate, especially given the dynamic
> >scoping rules: it would change the meaning of called functions too
> >drastically.
> >
> >On the other hand, getting rid of globals and making everything
> >module-local by default (with no local { ... } ) construct makes some
> >sense to me as a backwardly-compatible change. To set a "global"
> >variable, you would simply switch to the global module:
> >
> >rule set-global ( name : value * )
> >{
> > module { $($(<)) = $(>); }
> >}
>
> Makes sense to me :-) And given that it adds a form of code
documentation
> indicating where we are modifying globals it's even desirable.
>
> >Could you explain more precisely what problem you're speaking of,
what
> >functionality you're after, and how it would help?
>
> The problem I'm facing is that when we include a new Jamfile I have to
go
> search for it's corresponding project-root.jam. This is so we can
support
> cross-project dependencies. But different project-roots will very
likely use
> the same variables with different values, the immediate one is
PROJECT_ROOT
> and it's expected that constructs within a project, even when included
from
> another, work with the local versions. That also applies to things
like paths.
>
> It would help in that I could wrap the corresponding includes in a
> corresponding project module. This way the variables within the
project get
> scoped to the project module. No collisions and multiple projects can
coexist.
>
>
> -- grafik - Don't Assume Anything
> -- rrivera_at_[hidden] - grafik_at_[hidden]
> -- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]