Re: [jamboost] Re: target references

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-10-25 10:38:50

On Saturday 23 October 2004 18:23, David Abrahams wrote:
> Vladimir Prus <ghost_at_[hidden]> writes:
> > On Saturday 23 October 2004 09:25, David Abrahams wrote:
> >> >>> > , 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.
>
> I didn't mean into the very next milestone. Any upcoming milestone
> would be fine.
>
> > 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
> >
> > ?
>
> Something like that.

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?

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
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? CanI 
use "p1/p2" in the same place?

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

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

- Volodya