Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-07-16 07:58:14

David Abrahams wrote:

> > Maybe I'm starting to get your idea, though I need to digest it
> > more. I'm not yet sure why current Jamfiles are not portable or
> > interoperable.
> Suppose two projects choose the same project ID but need to be used
> together by some other project?

This is probably not as big problem as it seems. After all, all system-wide
libraries have to have different names already and it does not cause big
problems. But yea, a clash is possible.

> Incidentally, I'd like a project to be able to declare a project ID
> that has only local effect, so that, for example, subprojects of
> boost can refer to other boost subprojects as boost/whatever.

I think this is natural.

> > You mean, that project in 'some-path' does not declare project-id
> Right.
> > , or that /boost specified in 'use-project' overrides whatever was
> > specified there?
> That would be OK too. It begins to sound like "project IDs that have
> only local effect" that I described above.

Yea, kind of. For example, I can have two copies of boost and happily use them

use-project /boost-stable : some-path ;
use-project /boost-unstable : some-other-path ;

> >> for another, much less maintenance when new projects are
> >> added/renamed/etc.
> >
> > Yea, though with a mechanism to find all children project it's less
> > important.
> What I'm describing *is* a mechanism to find all the child projects.

Yes, it's a mechanism to find child project *given id of child project*. What
I was talking about is rather a mechanism to enumerate all child project
given location/id of top-level project.

> It's just a quetion of whether they're loaded lazily or eagerly.
> For another: no need to read/process Jamfiles of subprojects that
> aren't going to be used. You'd be able to simply write
> use-project /boost : some-path ;
> and then use
> boost/python//boostpython
> in your non-boost Jamfile without causing all the other subprojects
> of boost to be read in.

Yes. This probably can have efficiency gains if you use several large projects
and really depend only on some parts.

> >> More later.
> >
> > Do I have to expect another email? ;-)
> ??

The "more later" phrase can be interpreted as
- "I plan to write more about this later (in another email)"
- "more benefits can become apparent after some time".

I was trying to figure out which meaning was intended.

- Volodya


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at