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
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
> Yea, though with a mechanism to find all children project it's less
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 http://www.boost-consulting.com
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