Re: target references

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-12 11:15:39

Vladimir Prus <ghost_at_[hidden]> writes:

> David Abrahams wrote:
>
>> > When in foo/bar/baz/Jamfile,
>> >
>> > ..
>> >
>> > means "foo/bar", and if there's no Jamfile there, then "..//fu" is not
>> > correct, and ../..//fu should be used.
>>
>> So... the part before the // always refers to a path in the
>> filesystem?
>
> No, see below.
>
>> >> > ...or maybe we just need a very clear and complete description of
>> >> > these syntaxes in the documentation. It's possible that the reason
>> >> > I'm confused is that I've never seen the rules written down.
>> >
>> > I'll try to write down the rules:
>> >
>> > 1. The target-id with "//" in it refers to a target in some project. The
>> > part before "//" identifies the project, and can be either path to the
>> > directory where Jamfile for the other project is placed, or a symbolic
>> > id, matching those in 'project' rule for the referred project.
>>
>> Ack! That's really strange. If I use .. in the path before // it
>> _always_ means "up a directory", but other path elements before // may
>> be referring to project structure _or_ filesystem structure?
>>
>> I want to be able to name "boost" symbolically and then refer to
>> subprojects relatively. Can I do that?
>
> Ah... I understand what you mean. No... the symbolic project id is always 
> absolute: 
> /boost
> /boost/date_time
>
> or something like that. If you're in /boost/date_time, then you can't refer 
> to /boost by using ".." -- this is feature idea which never occured to me.

That's not what I mean.

If boost has been given an absolute project ID of /boost, I want to
be able to write something like:

/boost/libs/python/test

to refer to the python library's test project -- though I would strongly
prefer to have a clear distinction between project path elements and
filesystem path elements:

[boost]libs/python/test

or something

In fact, for Boost in particular, it would be nice to be able to say
something in a Jamfile about how to find its subprojects:

rule subproject-path ( subproject-name )
{
return libs/$(subproject-name)/build
}

So that once [boost] is identified, [boost/python] automatically
identifies the python subproject.
>
>> > The part after "//" is the
>> > name of main target in the referred project.
>> >
>> > 2. The target-id without "//" either refers to a project (using the rules
>> > above), or to a file. We first check if a project by this name exists,
>> > and if not, try interpreting the target id as name of the file.
>>
>> So in that case when checking for a matching project you assume that
>> only the last element in such a path names the target
>> (i.e. effectively replacing the final '/' with "//")?
>
> I'm not sure I understand. When looking up
>
> /boost/date_time
>
> in
>
> stage dt : /boost/date_time ;
>
> we first check if symbolic name /boost/date_time is known. If not, we try 
> looking at *directory* /boost/date_time and check if there's Jamfile in that 
> directory.

You can't answer my question without considering paths with more
elements:

exe foo : /boost/foo/bar ;

do you look for both /boost/foo//bar and /boost//foo/bar?

>> > 3. A target id which refers to target in Jamfile, not file, may specify
>> > additional properties in the end. All properties should include feature
>> > name, so the beginning of property list is identified by "/<"
>>
>> So far I am not suprised that I was confused. These rules are almost
>> impossible to explain coherently.
>
> Hopefully, we can improve them.

I hope so.

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