Re: [jamboost] Re: target references

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.

Good. 

> 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 zigzag.lvk.cs.msu.su 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 imap.cs.msu.su ([158.250.10.39])
by zigzag.lvk.cs.msu.su 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 n21a.bulk.scd.yahoo.com (n21a.bulk.scd.yahoo.com [66.94.237.50])
by imap.cs.msu.su (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 [66.218.69.6] by n21.bulk.scd.yahoo.com with NNFMP; 31 Oct 2004 20:37:03 -0000
Received: from [66.218.66.28] by mailer6.bulk.scd.yahoo.com 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 (66.218.66.217)
by m22.grp.scd.yahoo.com with QMQP; 31 Oct 2004 20:37:01 -0000
Received: from unknown (HELO main.gmane.org) (80.91.229.2)
by mta2.grp.scd.yahoo.com with SMTP; 31 Oct 2004 20:37:01 -0000
Received: from list by main.gmane.org 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 146-115-127-135.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com ([146.115.127.135])
by main.gmane.org 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 146-115-127-135.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <jamboost_at_[hidden]>; Sun, 31 Oct 2004 21:36:53 +0100
X-Injected-Via-Gmane: http://gmane.org/
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]>
<200410251938.50721.ghost_at_[hidden]>
X-Complaints-To: usenet_at_[hidden]
X-Gmane-NNTP-Posting-Host: 146-115-127-135.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:W5w2zROHbQ8MnLYrUbXM4cc7I1E=
Sender: news <news_at_[hidden]>
X-eGroups-Remote-IP: 80.91.229.2
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;
charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV 0.80/564/Fri Oct 29 18:58:02 2004
clamav-milter version 0.80j
on imap.cs.msu.su
X-Virus-Status: Clean
X-Scanner: exiscan *1COMS3-0000ls-00*o39B6/xXe7g*
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on zigzag.lvk.cs.msu.su
X-Spam-Level: 
X-Spam-Status: No, hits=-4.9 required=7.0 tests=AWL,BAYES_00 autolearn=ham 
version=2.64
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
answer.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
Yahoo! Groups Links
 --Boundary-00=_uQYrBCh35ZfHmNN--