Boost logo

Boost-Build :

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-15 10:27:50

Vladimir Prus <ghost_at_[hidden]> writes:

> David Abrahams wrote:
>> I'm trying to suggest that projects should never have to declare
>> their own ids. That will make it much easier to write portable and
>> interoperable Jamfiles.
> 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?

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.

>> > OTOH, in either case 'use-project' would need full id if you want to
>> > refer to specific project.
>> >
>> > use-project /boost/python : some-path
>> Not if you had
>> use-project /boost : some-path ;
>> and in boost's Jamfile some mechanism like:
>> locate-subprojects libs/\\1/build \\1 ;
>> There are several advantages here:
>> for one, there's no need to work around top-level project id
>> conflicts, because each project establishes its own notion of where
>> other top-level projects are.
> 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.

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

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


Dave Abrahams
Boost Consulting

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