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

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

On Friday 30 September 2005 20:46, David Abrahams wrote:

> >> 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.
>
> I understand now. The original was intended to be a reference
> document for the features related to changes we were making, not
> something to be dropped into the user documentation. For example, the
> section on Paths doesn't belong under "referring to projects," since
> there are plenty of other things you can do with paths.

Agreed.

> Okay.
>
> > * 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.
>
> Right.
>
> > * The leading "@" is not needed
>
> Right. You left one use of it in the revised docuument.

If you mean

use-project boost-release : @boost-1.33.0

then I did not notice it can be removed too. Yes, it can, agreed.

> Good. I think we agreed that a trailing slash could indicate "I
> really mean a directory."

In what context? When referring to a file in directory, or when?

> Another issue: you wrote,
>
> "The simplest project id is a path to another project's Jamfile."
>
> The problem with that description is that it gives the impression that
> a path to a Jamfile can always be used as a project ID, when in fact,
> any definition of a symbolic project ID can change make some legal
> paths to Jamfiles into illegal project IDs.

Right. In fact, I have another mental model of projects ids. We can use 
filesystem path, like:

../3rdparty/boost/libs/filesystem/build

On Linux, we can create symbolic links to simplify paths:

ln -s ../3rdparty/boost/libs/filesystem/ boost_fs

And symbolic project ids work exactly like that, except they work on
all systems, and are inherited. 

> Also, we don't "provide symbolic names," we provide the ability to
> _define_ symbolic names.

Right.

> I also think we've got trouble with the "source directory" concept.
> As far as I'm concerned, if some relative paths are interpreted
> w.r.t. to the source directory and some are interpreted w.r.t. the
> directory containing the Jamfile, we're in deep doo-doo. For now, I'm
> not trying to resolve the conflict: I'm leaving mentions of the source
> directory in your "referring to targets" section alone, and not trying
> to incorporate it into the other sections.

Things are tricky, because source-directory attribute can contain several 
paths, and source will be searched in all of them.

> If the "source directory" concept is important enough to keep (I have
> serious doubts; the KISS argument might apply here), I favor making
> all paths interpreted relative to that directory. I also favor
> changing the name to "current directory" and adding a "cd" rule, so
> that it's clear that a project reference followed by a rule that
> changing the source/current directory is not interpreted relative to
> the new directory. In other words, "source directory" is not a static
> property of the project and it doesn't just apply to sources. This
> still leaves some problems, I see. When interpreting X/Y in a Jamfile
> other than X's, relative to what is the search for Y performed? KISS
> indeed.

Probably "source-directory" is not that important concept and we can remove 
it, even breaking compatibility. OTOH, for Boost "source-directory" is pretty 
handy. Other solution look less convenient.

> Anyway, here's my cleanup of your revisions. I also made a few
> additions. I am beginning to hate the name "use-project" for this
> purpose so I've changed it to "project-id"

We talked offline and I tend to like project-id better, too.

> ====================
> User Manual Material
> ====================

.....
> ==================
> Reference Material
> ==================
.....

On first reading, I agree with everything here. I'll print it out and have a 
second look though.

> # returns the path to a directory corresponding to the given project
> # id interpreted in the given jamfile.
> def get_project_dir( jamfile, id ):
> elements = id.split('/')
> top_path = jamfile.local_aliases.getdefault(elements[0], None)

Which Python version is this? Mine doesn ot have 'getdefault' method in maps, 
though 'get' allows default value to be passed as second argument.

- Volodya

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