Re: RFC: Fixing project-ids and use-project

From: David Abrahams (dave_at_[hidden])
Date: 2005-01-17 14:23:41

Vladimir Prus <ghost_at_[hidden]> writes:

> I'm trying the clean up doc areas when Dave marked as problematic,
> and is stuck because I can't reasonably explain the current
> behaviour of project-ids and use-project. I think it's a sign that
> we really need to fix them up.
>
> How, I'm unsure how to fix theml without breaking every existing
> project

That may not be so terrible ;-)

> so I'd appreciate some help:
>
> Use case 1 ("external project"). I want to use C++ Boost. I'd expect
> to write
>
> use-project /home/ghost/boost/cvs ;
>
> and then have convenient ids for all boost libraries.

That's good, but for what it's worth, I don't think it would be an
unreasonable burden to ask users to specify the "local" project ID
(the one that can be used in the specifying project and all
subprojects) in use-project:

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

> Use case 2 ("internal project"). I want to use project id to refer to some 
> directory inside my project, to protect against directory reorganisation.

use-project internal-project-id : some/relative/path ;

> Use case 3 ("aliases"). I want to use two different project id for the same 
> project. Or, I want two use two different project ids for two different 
> project, even if they define the same project id.

use-project project-id-1 : some/relative/path ;
use-project project-id-2 : some/relative/path ;

> Problem 1. The 'use-project' rule requires to always specify project-id, even 
> if the referenced project already defines a project-id. This is syntax 
> inconvenience and can be easily fixed.

I guess I don't think it's a big problem, but if it can be fixed
easily, so much the better.

> Problem 2. The 'use-project' rule requires the the specified project-id is 
> equal to that project-id specified by the referenced project. So, it's not 
> possible to give alias to a project id. This is easy to fix, too.

Good.

> Problem 3. The project ids are all "global" -- they share the same namespace. 
> It means that something like
>
> use-project boost-cvs : /home/ghost/boost/cvs ;
> use-project boost : /home/ghost/boost/release ;
>
> is not possible, since Jamfiles in both location will define the same global 
> project id "boost".
>
> If we want to solve the third problem, it means that we need "local" project 
> ids. So, "/boost//" can mean different things in different Jamfiles.

Yes.

> But then we have:
> Question 1. Should there be any meaning of "relative" project ids. Now, all 
> ids start with "/". If ids can be local, it's reasonable to drop "/" from 
> them. But that would require updating of all Jamfiles, which is not 
> desirable.

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.

> Problem 4. Subprojects. After 
>
> use-project /home/ghost/boost/cvs ;
>
> I want to use all Boost libraries. I also want to be able to use them after 
>
> use-project boost-cvs : /home/ghost/boost/cvs ;
>
> There are two ways to make it work: automatically translate ids of
> subprojects 

Sounds good.

> or add a number of "alias" targets to Jamroot. 

Sounds inconvenient. Which Jamroot? The one in boost or in my
project?

> In the first case, one will be able to use
> "/boost-cvs/filesystem//boost_filesystem", and in the second case:
> "/boost-cvs//filesystem".

?? Why are the target names different in these two cases?

> The first case requires that Jamroot somehow provide the list of all
> the subprojects (we don't have a documented way to do that), 

Only in the case where subprojects are not located in a direct
subdirectory, right?

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

> There are some further questions, but so far I can't formulate them
> without going into implementation details.
>
> Feedback is very welcome!

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com