Re: [jamboost] Re: target references

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-07-15 02:38:15

David Abrahams wrote:

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

Alas :-( As I've said in another email, I wrote that backward -- if there's 
'//', 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.
>
> So... in directory foo, to refer to a file foo/bar/baz.cpp, I have to
> write: foo/bar//baz.cpp?

Nope. Just foo/bar/baz.cpp

> > 2.1 The name of a target should be exactly the name specified in
> > Jamfile.
>
> Which Jamfile, and how is it specified?

Another wording:

2.1 The name of a target should be exactly the name specified in
project referred by the part before "//"

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

Yes.

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

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

I see. But those users sent a lot of complaints in other areas, so I'm not 
sure they'd not mention target id is they were very confusing.

Anyway, what I'm really trying to do (besides deciding on the right syntax), 
is avoid asking the users to update Jamfiles once again, so probably we need 
to support existing syntax (maybe even without docs) for quite some time.

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

In some sense you need to somehow refer to all sub-projects from top-level 
Jamfile. For example, when installing you need the list of all libraries. In 
V1, that list is computed via GLOB magic -- which V2 can do as well -- but we 
still need the list of all libraries. And we we have it, we can load 
Jamfiles.

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

I don't think I planned that you can take any project -- like python, and move 
it into different project without also moving top-level Boost Jamfile. In 
fact, because some requirements are inherited from Boost Jamfile, moving one 
project is not possible.

Likewise, I did not plan that -- or rather, did not though -- about renaming 
top-level project and automatically renaming all the children. 

What I surely did want was specifying project-id relative to parent's 
project-id, so that 

project /boost/python ;

becomes 

project python ;

That never was implemented, though I don't know why -- now it seems 
straight-forward task.

- Volodya