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