Re: [jamboost] Re: RFC: Fixing project-ids and use-project

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-01-18 09:35:23

On Tuesday 18 January 2005 16:36, David Abrahams wrote:

> >> use-project boost : /home/ghost/boost/cvs ;
> >
> > Actually, I was stuck trying to describe why you need to specify
> > project id both in 'use-project' and in the referred project.
>
> When you say “referred project” I assume you mean the project being used.

Yes.

> It seems to me that the project being used only needs to specify
> its own project ID in order to provide a default project name that can
> be used for absolute project IDs, e.g. by its subprojects.

You mean by subprojects of the used project? I think it will do no harm is the 
same name will be used as project id when you specify only directory location 
to use-project.

> >> I don't understand. The fact that dropping the leading "/" is allowed
> >> doesn't make it required. Users can choose whether to switch to
> >> relative IDs or not.
> >
> > I can try to split the question.
> >
> > 1. If the project id introduced by the 'use-project' rule is
> > available only in the project which contains 'use-project' call and
> > in children of that project, is it good idea to have "/" in the
> > project-id. Won't users assume that ids with slash are 'global'.
>
> One possibility is that the rootedness (or "absolute-ness") of the
> project path doesn't have anything to do with its scope. For example:
>
> use-project /foo : path/to/foo ;
>
> tells us where to find the project with ID "foo".
>
> use-project bar : path/to/bar ;
>
> tells us where to find the subproject of this project called "bar."

Seems reasonable. 

> > 2. If we allow to drop "/", won't user be confused as well, and assume
> > such project-id are relative to the *current* project -- i.e. project
> > where such id is *used*?
>
> Sounds like the meaning I gave above.
>
> > Today, I think that the right approach would be to make project id
> > local for each project, but still require leading slash. So, you can
> > have '/boost' mean different things in different projects.
>
> I agree, if by "require leading slash" you mean "require a leading
> slash on absolute project IDs." I think there's probably a place for
> relative project IDs.

I don't yet have a clear understanding how relative project IDS will work, so 
I don't yet propose to introduce them. So, yes -- I meant leading slash on 
absolute project IDs.

> >> ?? Why are the target names different in these two cases?
> >
> > It was a attempt to further simplify things -- the Jamroot can use
> > arbitrary names for alias, for example
> >
> > alias filesystem : libs/filesystem//boost_filesystem ;
>
> I understand now. I don't like the alias approach much.

It surely saves on typing.

> >> > and the second case requires manual changes for each new
> >> > library. But maybe, it can be automated.
> >> >
> >> > Question 2. Which variant is better?
> >>
> >> I don't think you've described them clearly enough. I believe some
> >> sets of example projects may be required in order clearly illustrate.
> >
> > Ok, here we go.
> >
> > Example 1.
> >
> > Boost Jamroot:
> >
> > project boost ;
> >
> > # 'subproject' is a new rule. It specifies that whenever this project
> > is # used via 'use-project', the project id specified in this rule must
> > also # be made available.
> > subproject boost/filesystem : libs/filesystem/build ;
>
> I'd prefer it if this said:
>
> subproject filesystem : libs/filesystem/build ;
>
> It's more consistent.

Okay.

> > Client Jamfile:
> >
> > using boost-cvs : /home/ghost/Work/boost ;
> > # Makes two project ids avaiable:
> > # '/boost-cvs' and '/boost-cvs/filesystem'. This requires
> > # that we walk though the list of subprojects defined in Boost's
> > # Jamroot and replace 'boost' with 'boost-cvs'.
>
> Not quite, if we do it the way I suggested above.

You mean "subproject filesystem". Yes, you're right.

> > exe a : a.cpp /boost-cvs/filesystem//boost_filesystem ;
> >
> > Instead of creating a new 'subproject' rule we can use 'use-project'. So,
> > Boost Jamroot will be:
> >
> > use-project boost/filesystem : libs/filesystem/build ;
>
> use-project filesystem : libs/filesystem/build ;
>
> > This will at the same time make '/boost/filesystem' available for all
> > boost subprojects, and make it available tf all clients of Boost.
>
> This seems reasonable.

I start to see value in relative project IDs. But still, if somebody writes 

use-project /boost/filesystem : libs/filesystem/build ;

in Boost's Jamroot, will writing

use-project /boost-cvs : /home/ghost/Work/boost ;

in some client Jamfile make 

/boost-cvs/filesystem 

known in that Jamfile? Or not? Or we should emit an error?

> > Example 3.
> >
> > Boost Jamroot:
> >
> > project boost ;
> >
> > # given a project id, relative to 'boost', returns
> > # the directory where that project is located.
> > rule project-id-to-location ( id )
> > {
> > .............
> > }
>
> The following is meant to be in the client Jamfile, I presume:
> > exe a : a.cpp /boost-cvs/filesystem//boost_filesystem ;
>
> I like this one as long as there's a default project-id-to-location
> implementation.

That default implementation will probably only look at 'use-projects' which 
occur in a Jamfile, right?

> > which is certainly doable, though some extra work.
> >
> > Now the question is what examples do we want to support.
>
> I think you have my answers now.

Yes, thanks!

- Volodya