Re: [jamboost] Project IDs

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-03-03 04:00:33

David Abrahams wrote:
> Vladimir Prus <ghost_at_[hidden]> writes:
> > David Abrahams wrote:
> >> I was just reading through boost_build_v2.html, and even though I was
> >> in on the design of these features, I've forgotten a lot, so I here
> >> are my remarks:
> >>
> >> 1. target/Project IDs are mentioned without any introduction. Some
> >> introductory description needs to be written. I'd do it, but I'm
> >> not clear on the concepts anymore ;-S
> >
> > I'll do this later today, offline.
>
> Done yet? ;-) (no rush).

Have some doc changes locally. Will commit in the evening (gotta work on 
something else).

> >> 2. The example shows:
> >>
> >> use-project /lib1 : lib/lib1 ;
> >> exe app : app.cpp @/lib1/lib1 ;
> >>
> >> What's the meaning of the initial slash?
> >
> > It means that /lib1 is global project id.
> >
> >> What would it mean if I wrote:
> >>
> >> use-project lib1 : lib/lib1 ;
> >> exe app : app.cpp @lib/lib1 ;
> >
> > In theory, this should declare local project id.
>
> Is that relative to the root of the current project, or something
> else? 

Yes, that's the suggested semantic.

> What's the scope of this name? IOW, in which Jamfiles can I
> use the name @lib/lib1 and have it mean the same thing as it does
> here?

In all children projects, unless some of them declares another "lib1".

> > In practice, this is not
> > supposed to work.
>
> I don't understand what you mean. If you'd said "in practice, this
> doesn't work" it would make sense to me. What's "supposed to
> work" usually corresponds to what "should happen in theory."

Me is ambiguous, as usual. This was never implemented or tested.

> >> 3. What's the scope of these target IDs? Suppose two different
> >> projects do "use-project /lib1"?
> >
> > Since they try to declare /lib1, which is global project-id, they better
> > associate it with the same Jamfile.
>
> We had some discussion of local project renaming at one point, didn't
> we? The idea, IIRC, was to have some kind of backdoor for dealing
> with conflicts at the top level, and possibly for dealing with
> different versions of the same project.

You are right. We meant something like

use-project /boost-1.29 : /some/path ;
use-project /boost-1.30 : /some/path ;

as usual, the problem is in design and use cases. 

- Volodya