Re: target references

From: David Abrahams (dave_at_[hidden])
Date: 2004-11-02 12:04:34

Vladimir Prus <ghost_at_[hidden]> writes:

> On Sunday 31 October 2004 23:36, David Abrahams wrote:
>
>> > 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."
>
> It's being "using" historically. It's possible to use "project" for this case 
> too, but given that usages for ordinary project:
>
> project boost : requirements <include>. ;

> and using of other project
>
> project boost : /home/ghost/Work/boost ;
>
> are pretty different, there's a question how to distinguish both usages, and 
> whether one name for both usages is good. Here, I don't know whether 
> uniformity or explicitness is more important.

project boost : . : requirements <include>. ;

Although "use-project" is fine.

>> > 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?
>
> A rule which is defined in top-level Jamfile (in the same directory where 
> project-root.jam is).
>
>> > 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.

I still think #3 is viable.

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

Uh, no. When I wrote that, I assumed that locate-subprojects was
supplied by the build system, and... well I guess it *could* inject a
rule into the top-level Jamfile but... it isn't, on its face,
defining a rule.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com