Re: [jamboost] Boost.Build V2, load behaviour part 2.

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-04 01:59:06

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
To: <jamboost_at_[hidden]>
Sent: Wednesday, April 03, 2002 10:13 AM
Subject: Re: [jamboost] Boost.Build V2, load behaviour part 2.

> David Abrahams wrote:
>
> > I hope you get well soon! Please rest and feel better,
>
> Thanks you. I'm back to coding now, waiting for another virus (or
whatever
> that was) to come my way!
>
> > Aww, heck, it's not in the CVS!
> > I have something on my disk. Where did it come from?
>
> Eeeh... I don't recognize that code, either. Probably it was you who
wrote
> it? :-)
> Anyway, my version is at
> http://chronos.cs.msu.su/~ghost/projects/boost-build/project.jam

Cool! We have 3 versions!

> The question is what we do about it. There are two issues:
>
> 1. Both Rene's initialization code and my project.jam do some
crawl-up. Since
> crawl-up is needed in initialization anyway, I don't mind using Rene's
code.
> Besides, it gives more reasonable error messages.

Good plan.

> 2. All jamfiles in one module or all jamfiles in separate modules.
This is a
> big question -- I always thought that module-per-jamfile is better,
largely
> because of similarity of this approach to object-oriented programming.

When in doubt, I prefer separation of namespaces.

> In
> fact, there more than one variable that describe a project and so
making each
> Jamfile a module seems reasonable, while the only drawback is using
variables
> defined in project root.

I hope that users won't do much communication via variables. However,
see Steve K's posting on variable exporting. I think it might make sense
to have something similar. I favor a style of exporting which makes
variables visible in everything lower down in the (sub)project
hierarchy. Finally, I think we shouldn't implement this until there is a
demonstrated need.

> Frankly, I never realized we have this problem. But:
> 1. It probably not very important. First, we'll inherit includes from
parent
> project (and from project root, maybe?)
> 2. I believe (and I think we've talked about it some time ago), that
backward
> propagation of requirement should be supported. E.g. -- a using
<lib>boost in
> sources will automatically add boost includes.

Agreed.

> These two things will make the problem less important. If stealing
variable
> names from project root is really needed, we can make a rules which
returns
> the list of variable, as David suggested.
>
> So, what we decide?

I find myself in favor of isolated namespaces.

> BTW (not sure how this relates to the discussion). If we have
>
> module A {
>
> x = 1 ;
>
> module B {
> echo $(x) ;
> }
> }
>
> Will "1" be printed, IOW, will x be visible from B?

No, every module has a completely distinct namespace "stack"; entering B
swaps out A's definitions (including locals) and swaps in B's.

-Dave