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

From: David Abrahams (dave_at_[hidden])
Date: 2005-01-18 10:29:24

Vladimir Prus <ghost_at_[hidden]> writes:

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

Yes.

> I think it will do no harm is the same name will be used as project
^^---"if"
> id when you specify only directory location to use-project.

In principle I agree with that, although it seems strange to say,
"I'll tell you where the project is, but I'm willing to call it by
whatever name it gives itself," because... 

1. I may have to use the name in many places.

2. The project could change its own name quite easily, which would
break all my usages.

3. It could be placed in a location that gives no clue as to what it
is. For example, boost might be in:

/usr/lib/draft

which would make the use-project invocation look pretty
mysterious.

I guess it just seems like unneccessary flexibility that doesn't yield
great savings. When you give the user options, they have to be
documented and maintained, and this seems like one area where you can
trim options without really hurting anyone. Being disciplined about
not overgeneralizing is important.

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

It seems pretty obvious to me. If Jamfile whose absolute project ID
is /foo mentions a relative project ID bar/baz, that is equivalent to
the absolute project ID /foo/bar/baz.

> so I don't yet propose to introduce them. So, yes -- I meant
> leading slash on absolute project IDs.

Well, I think relative project IDs could yield significant savings in
expressivity. Plus it seems to mesh nicely with syntax I proposed and
you liked for the subproject declarations below.

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

Not for the person who has to write the aliases.

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

Aha! :)

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

Yes, of course. Why not?

> Or not? Or we should emit an error?

Why should it be 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?

That default implementation will implement the semantics of Example 1
:-)

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

And now, even more so :-)
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com