Re: target references

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-14 14:52:06

Vladimir Prus <ghost_at_[hidden]> writes:

> David Abrahams wrote:
>
>> > 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.
>
> Okay.
>
> 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 file, otherwise it refers to target.

?? Seriously ??

The standard syntax everyone knows for referring to files, a path with
no "//"s in it, always refers to a non-file, and to refer to a file
you have to use the funky new syntax that uses "//"??

_That_, my friend, is counterintuitive [not to mention the notion of
"a target reference that doesn't refer to a target", but I can live
with that one for now]

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

So... in directory foo, to refer to a file foo/bar/baz.cpp, I have to
write: foo/bar//baz.cpp?

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

Now you're contradicting yourself. According to what you wrote above
there is no "//" in a target reference that refers to a target.

> 2.1 The name of a target should be exactly the name specified in
> Jamfile. 

Which Jamfile, and how is it specified?

> 2.2. The part before "//" can identify a project in two ways: by specifying 
> directory of Jamfile, or by specifying project id previously passed to the 
> invocation of the 'project' rule. 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.

So project ids are always absolute?

> I hope I've specified everything. If not, let me know and I'll fill the holes.

How do project ids get assigned?

>
>> > 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
>
> Ok, I understand. I wonder though, why nobody complained about it
> yet....

Your userbase is those people willing to live on the bleeding edge
using pre-release software. Just because they're not complaining
about lack of explicitness and comprehensibility doesn't mean the
interface and documentation will pass muster with the rest of the
world.

>> >> 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?
>
> You start by saying
>
> use-project /boost : path-to-boost ;
>
> after that, top-level Boost Jamfile is loaded and in turns loads Boost.Python 
> Jamfile, which registers the "/boost/python" id.

So boost has to explicitly load the Jamfiles of any sub-projects that
are to be found relative to its project ID? I find that bad from a
maintenance POV.

One of your original goals for sub-projects, IIRC, was that they be
composable into new project hierarchies. That means the boost/python
sub-project shouldn't be forced to know its own absolute project ID.

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