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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-04-03 10:13:42

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

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.

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. 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. 

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.

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?

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?

- Volodya