Re: target references

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

Vladimir Prus <ghost_at_[hidden]> writes:

> David Abrahams wrote:
>
>> > 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
>
> Ouch. It seems you're asking fore even more complex syntax. 

I'm asking for an explicit syntax. The semantics of the current
syntax are way too vague.

> What we have now 
> is:
>
> 1. Target-id is either file or target in Jamfile
> 2. If it's target in Jamfile, it can be in the current Jamfile, or elsewhere
> 3. If it's elsewhere, we can use either filesystem path to refer to location 
> of other Jamfile, or its symbolic project id

That's only half the summary. You haven't described how the syntax
is interpreted to yield those semantics (except in a bunch of
incomplete fragments from prior messages). Gather it all in one
place so we can look at it.

> What you propose that 
> 4. It's possible to refer to other Jamfile using first symbolic project id and 
> then filesystem path relative from that.

What I propose is that:

project IDs are bracketed (or something).
filesystem paths are un-bracketed

We probably also need some way to clearly denote a target name within
a project (as opposed to a filename). Possibly target names should
also be bracketed.

> I don't think I immediately like the latter idea because we'd really need some 
> new syntax, e.g. [] that you've used. I think it's not that hard to specify 
> ids like /boost/thread in individual library Jamfiles.

The problem is *not* that it's hard to specify the id. The problem
is that:

I can't understand what the specifications mean!!

>> 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.
>
> It would be nice, but I think manual specification is acceptable.

I don't. How do I refer to the boost/python project from a project
unrelated to Boost?

>> > 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?
>
> I don't understand. The /boost/foo/bar refers to *project*. Two other syntax 
> refer to targets in some projects. There's no way they can be equal, and 
> naturally I can't look for /boost/foo//bar.
>
> Let me try again:
>
> - we check if there's /boost/foo/bar/Jamfile file
> - we check if there were some Jamfile which did
>
> project /boost/foo/bar ; 

Wow. Well, I've lost track of the complete picture. As I said, I
need to see the syntax and semantics all written down together.

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