Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-01 03:43:26

On Wednesday 01 December 2004 00:47, David Abrahams wrote:
> Vladimir Prus wrote:
> > We need to decide if explicit rule provided by user, or more declarative
> > mechanism is better.
> >
> > There are two questions:
> > 1. Lazy or eager. The subprojects can be lazy loaded -- they are loaded
> > only when needed by other projects. The top-level project just maps
> > project ids into directory locations. In eager mode, all subprojects are
> > found and loaded automatically. I think lazy is better for performance
> > reasons.
> Agreed. And I see no disadvantages, do you?

No, I don't see any.

> > 2. User rule or declarative mechanism. In first, user provides a rules
> > which maps ids to locations. In second, he describes the mapping is some
> > other terms. I think user rules is simpler, and declarative mapping can
> > be implemented by injecting the rule, so maybe we should initially allow
> > only user-defined rule.
> That's okay with me.


> I seem to have some memory that I agreed to write the new documentation
> for this feature so you could implement it, but I can't find any record
> of it in the archives (?)

I've attached that mail of yours. If you need to recall something else, I can
sent you all messages in this thread.

- Volodya
 --Boundary-00=_uQYrBCh35ZfHmNN Content-Type: message/rfc822;
name="forwarded message"
Content-Transfer-Encoding: 8bit
Content-Description: David Abrahams <dave_at_[hidden]>: [jamboost] Re: target references
Content-Disposition: inline

Return-path: <sentto-4392937-7840-1099255023-ghost=cs.msu.su_at_[hidden]>
Envelope-to: ghost_at_[hidden]
Delivery-date: Sun, 31 Oct 2004 23:39:06 +0300
Received: from mail by with spam-scanned (Exim 3.36 #1 (Debian))
id 1COMSr-0000mj-00
for <ghost_at_[hidden]>; Sun, 31 Oct 2004 23:38:14 +0300
Received: from ([])
by with esmtp (Exim 3.36 #1 (Debian))
id 1COMS3-0000ls-00
for <ghost_at_[hidden]>; Sun, 31 Oct 2004 23:37:23 +0300
Received: from ( [])
by (8.12.11/8.12.11) with SMTP id i9VKb9CY063065
for <ghost_at_[hidden]>; Sun, 31 Oct 2004 23:37:17 +0300 (MSK)
(envelope-from sentto-4392937-7840-1099255023-ghost=cs.msu.su_at_[hidden])
Received: from [] by with NNFMP; 31 Oct 2004 20:37:03 -0000
Received: from [] by with NNFMP; 31 Oct 2004 20:37:03 -0000
X-Yahoo-Newman-Property: groups-email
X-Sender: dave_at_[hidden]
X-Apparently-To: jamboost_at_[hidden]
Received: (qmail 29896 invoked from network); 31 Oct 2004 20:37:01 -0000
Received: from unknown (
by with QMQP; 31 Oct 2004 20:37:01 -0000
Received: from unknown (HELO (
by with SMTP; 31 Oct 2004 20:37:01 -0000
Received: from list by with local (Exim 3.35 #1 (Debian))
id 1COMRZ-0008UG-00
for <jamboost_at_[hidden]>; Sun, 31 Oct 2004 21:36:53 +0100
Received: from ([])
by with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <jamboost_at_[hidden]>; Sun, 31 Oct 2004 21:36:53 +0100
Received: from dave by with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <jamboost_at_[hidden]>; Sun, 31 Oct 2004 21:36:53 +0100
To: jamboost_at_[hidden]
Lines: 108
Message-ID: <umzy2lj5u.fsf_at_[hidden]>
References: <ud635kx7s.fsf_at_[hidden]>
<200410231234.33673.ghost_at_[hidden]> <ufz45ms39.fsf_at_[hidden]>
X-Complaints-To: usenet_at_[hidden]
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:W5w2zROHbQ8MnLYrUbXM4cc7I1E=
Sender: news <news_at_[hidden]>
From: David Abrahams <dave_at_[hidden]>
MIME-Version: 1.0
Mailing-List: list jamboost_at_[hidden]; contact jamboost-owner_at_[hidden]
Delivered-To: mailing list jamboost_at_[hidden]
Precedence: bulk
List-Unsubscribe: <mailto:jamboost-unsubscribe_at_[hidden]>
Date: Sun, 31 Oct 2004 15:36:13 -0500
Subject: [jamboost] Re: target references
Reply-To: jamboost_at_[hidden]
Content-Type: text/plain;
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV 0.80/564/Fri Oct 29 18:58:02 2004
clamav-milter version 0.80j
X-Virus-Status: Clean
X-Scanner: exiscan *1COMS3-0000ls-00*o39B6/xXe7g*
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on
X-Spam-Status: No, hits=-4.9 required=7.0 tests=AWL,BAYES_00 autolearn=ham
X-UID: 7207

Vladimir Prus <ghost_at_[hidden]> writes:

> Ok, I'd like to nail down the direction we take. You've said (long ago):
>> 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.
> Support for
> using /boost-stable : some-path ;
> would allow you to change the name the project is known elsewhere. I
> think that it's a good feature in itself, but not very important. Do
> you think otherwise?

I think it's moderately important for the sake of modularity.

I don't understand why that is "using" and not "project."

> If we agree so far, then we need to decide on a method of avoiding
> specifying project ids completely.
> Basically, this could be either:
> 1. top-level rule which maps projects ids to locations

What does "top-level" mean?

> 2. ability to prepend target id to the id declared in subproject, so that
> project python ;
> define project id boost/python.
> 3. Both options.
> In case of (2) there's a question if we allow non-global project ids. For
> example, can I use "top-level/p1/p2" in project at in top-level/p1/p3? Can I
> use "p1/p2" in the same place?

I don't see any reason to rule out any of the things you've
mentioned, but then I may not have a very complete picture of what
you're talking about.

>> > Another question is what to do with indirect lookup -- that idea of yours
>> > that top-level Jamfile should provide a method to map project ids to
>> > Jamfile locations. I'm thinking there could also be a similar mechanism
>> > for targets, so that I could just write:
>> >
>> > /boost//program_options
>> >
>> > and that would be translated to
>> >
>> > /boost/libs/program_options/build//boost_program_options
>> >
>> > I think this feature is good too, and would be a good addition to
>> >
>> > using /boost-stable : ...... ;
>> >
>> > What do you think?
>> It sounds attractive, but also has the ring of a premature
>> generalization about it.
> I though it originates from you. Here a part of a post of yours:
>> Not if you had
>>     use-project /boost : some-path ;
>> and in boost's Jamfile some mechanism like:
>>     locate-subprojects libs/\\1/build \\1 ;

This is your "option 1" above, right?

>> 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.
>> for another, much less maintenance when new projects are
>> added/renamed/etc.

I remember now. Yes, I think this is important.

>> > And the last question: would you be interested in implementing
>> > some of this functionality. The targets.find rule is pretty nice
>> > by now, and your contribution will be very appreciated!
>> Interested? Yes. I'm not sure I'm capable either in time or
>> knowledge, though.
> Since you was initially interesting in documenting the behaviour,
> maybe that's what can be done in the first place. If you document
> the way target references should work, we'll be able to understand
> more, and adjust the code more quickly? Maybe the documentation
> should not be in "final" form, just a basic use cases, but anyway
> that would help a lot.

That's not a bad idea. I'll try to pick it up after I get your

Dave Abrahams
Boost Consulting
Yahoo! Groups Links

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