Re: [jamboost] Re: target references

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-11-03 02:34:09

On Tuesday 02 November 2004 20:04, David Abrahams wrote:

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

Seems confusing.

> Although "use-project" is fine.

Ok.

> >> > 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 think so, too.

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

We need to decide if explicit rule provided by user, or more declarative 
mechanism is better.

There are two questions:
1. Lazy or eager. The subprojects can be lazy loaded -- they are loaded only 
when needed by other projects. The top-level project just maps project ids 
into directory locations. In eager mode, all subprojects are found and loaded 
automatically. I think lazy is better for performance reasons.

2. User rule or declarative mechanism. In first, user provides a rules which 
maps ids to locations. In second, he describes the mapping is some other 
terms. I think user rules is simpler, and declarative mapping can be 
implemented by injecting the rule, so maybe we should initially allow only 
user-defined rule.

- Volodya