Re: [jamboost] Re: Solving the target reference problems

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-09-28 01:20:04

On Tuesday 27 September 2005 20:42, David Abrahams wrote:
> Vladimir Prus <ghost_at_[hidden]> writes:
> > So, here's a refined version. Comments are welcome!
>
> What encoding did you use? 

Content-Type: text/plain;
charset=ISO-8859-1

> I'm seeing underscores everwhere I had two 
> adjacent spaces in the original document. 

I don't understand this, sorry. I did not notice any adjacent spaces in the 
original, and don't see any underscores in the new version.

> I'm unhappy with the 
> reordering of sections and the dropping of the notion "project ID
> constant," 
> which had conceptual value because of the way it applies in 
> subprojects (and is adjusted like a path constant) until overridden,

Ok, I did not notice that extra meaning you put in the term. However, I'm not 
happy with "project ID constant" still. It's not just constant that happens 
to be project ID, it's also name that's not related to filesystem path, 
that's why I stick "symbolic" everywhere. Note also that those project ID 
constants are not available with $(NAME) syntax, like orginary constants are.

> and with the removal of the section on project ID construction, 

It's not removed. If fact, it's still there without any changes.

> and 
> the moving of some information from there into the introductory
> section; that now has too much detail.

Previously, there were no overview at all. I had to gather the basic idea by 
looking at the *entire* document.

>
> Did you actually apply the changes we decided in the chat you posted?
> Could you post a condensed list of changes?

* We clarified the process that resolves project refereces --
basically that we take left-most element, look it up in the
order given in "Ambiguities" section, get new project and continue

* We clarified that after: 

use-project boost : ...... ;

in project foo, one can use "boost" in that project and one can use
"foo/boost" elsewhere. There's no way to declare project ID that's
not accessible from outside.

* The leading "@" is not needed

* The double slash is indeed not needed. We agreed that target names with 
slash in them are disallowed.

Changes that did not make into the document:

* If project defines symbolic project ID "serialization", it's not possible
to access "serialization" subdirectory under that project. If such need
arises, we'll introduce some escaping syntax.

- Volodya

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2