> >>> > , 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.
> >>
> >> Yea, kind of. For example, I can have two copies of boost and happily
> >> use them by
> >>
> >> use-project /boost-stable : some-path ;
> >> use-project /boost-unstable : some-other-path ;
> >
> > Right!
>
> Is there any chance of getting the features discussed in this thread
> into an upcoming milestone? This is the only functionality that
> really makes sense to me, so it becomes a de-facto prerequisite for
> me before I can really document how target references work ;-)

It's not very likely I'll be able to implement them myself. I'd like to
release that milestone in the middle of the next week, and it seems like I
must prepare some preliminary version of a PhD thethis during the same time.

But while it's too late for release, implementing this functionality is
certainly desired.

IIRC, the remaining issue was what to do with explicit absolute names.

For example:

top-level Jamfile has

project boost ;

another Jamfile has

project boost/program_options ;

you write

using /boost-stable : some-path ;

Now, is it possible to use

/boost-stable/program_options

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

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!