Re: target references

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-15 06:25:59

Vladimir Prus <ghost_at_[hidden]> writes:

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

Why don't you write up the summary again with the correction and we
can look at it afresh?

>> > 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 "//"

OK.

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

Then the leading slash is redundant :(

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

...but at least I understand it.

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

People who "just want to get something done" will accept and
repeatedly apply a pattern without really understanding it. Not
everyone can work that way... especially if they're trying to write
documentation ;-). I hope you agree that someone needs to write the
rules down in the docs. If the rules are too complicated to
understand, the docs will confuse people.

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

Yes, I was thinking the same thing. We could probably add a
command-line option that updates Jamfiles automatically ;-)

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

I understand... but do you think that's a good idea? If there were
some rules for searching based on project path it would reduce the
burden of project maintenance and the chance of error.

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

Maybe it was Ali. I distinctly remember discussing the idea that an
existing "top-level" project could be moved into another project as a
sub-project.

> In fact, because some requirements are inherited from Boost Jamfile,
> moving one project is not possible.

Maybe not in the case of Boost, but perhaps in general?

> Likewise, I did not plan that -- or rather, did not though -- about
^^^^^^
"think"?
> 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.

Right now a top-level project needs to name each of its subprojects,
and each subproject needs to name itself. I think it would be
valuable to reduce the amount of redundancy in the system.

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