Boost logo

Boost-Build :

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

 


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk