Re: [jamboost] Re: target references

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-11-01 02:54:02

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.

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

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

Ok, we agree on this.

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

Great!

- Volodya