Re: target references

From: David Abrahams (dave_at_[hidden])
Date: 2004-10-31 15:36:13

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