Re: target references

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-15 08:17:14

Vladimir Prus <ghost_at_[hidden]> writes:

> David Abrahams wrote:
>
>> Why don't you write up the summary again with the correction and we
>> can look at it afresh?
>
> Here it goes:
>
> 0. Target-reference refers either to file or a target in some project. The 
> decision is made syntantically. If targer reference has "//" in it, it refers 
> to a target, otherwise it refers to a file
>
> 1 Target reference which refers to file is interpreted as file name relative 
> to the source directory of the project where target reference is used.
>
> 2. Target reference which refers to target constists of two parts. The part 
> after "//" names a target in Jamfile. The part before "//" identifies a 
> project.
>
> 2.1 2.1 The name of a target should be exactly the name specified in
> project referred by the part before "//"

When you say "specified" you mean "by calling the 'project' rule" as
described below.

> 2.2. The part before "//" can identify a project in two ways: by specifying 
> directory of Jamfile, or by specifying symbolic project id. There's no 
> syntantic differences between those two ways: we first look if project with 
> such id exists. If not, we interpret the part before "//" as path to Jamfile.
>
> Project ids are assigned by calling the 'project' rule in Jamfile, passing the 
> project id as the first argument. The project ids are always absolute, 
> e.g. /boost/python

It's beginning to look comprehensible, though not yet ideal.

>> Then the leading slash is redundant :(
>
> Yea. The question is if we want to just remove the leading slash, or allow 
> relative project ids. The latter approach seems better -- while I never 
> lacked relative ids much they would make the syntax more "complete".

A possible problem is that if you allow relative project ids you then
have no way to explicitly refer to a Jamfile via a path in the
filesystem that happens to match a project id.

>> >> > I hope I've specified everything. If not, let me know and I'll
>> >> > fill the holes.
>> >>
>> >> How do project ids get assigned?
>> >
>> > It's assigned when Jamfile calls the 'project' rule. The id passed
>> > to the 'project' rule should be always absolute.
>>
>> Seems like it makes more work in explicitly specifying project ids
>> than it should have to, and allows for possibly-confusing errors, like
>> a sub-project of /boost named /boast/foo
>
> We sure can make declaring ids relative to parent work. I might do it rather 
> quickly if we decide it's needed (though I might decide to refactor 
> project.jam at the same time)

I'm trying to suggest that projects should never have to declare
their own ids. That will make it much easier to write portable and
interoperable Jamfiles.

> OTOH, in either case 'use-project' would need full id if you want to refer to 
> specific project.
>
> use-project /boost/python : some-path

Not if you had 

use-project /boost : some-path ;

and in boost's Jamfile some mechanism like:

locate-subprojects libs/\\1/build \\1 ;

There are several advantages here:

for one, there's no need to work around top-level project id
conflicts, because each project establishes its own notion of where
other top-level projects are.

for another, much less maintenance when new projects are
added/renamed/etc.

More later.

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