Re: Solving the target reference problems

From: David Abrahams (dave_at_[hidden])
Date: 2005-10-04 11:34:47

Vladimir Prus <ghost_at_[hidden]> writes:

> On Friday 30 September 2005 20:46, David Abrahams wrote:
>
>> 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?

I don't remember, so let's forget it :)

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

Right.

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

Oh, then it's mis-documented and mis-named. It should be called
source-path.

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

Well, one way to sensibly unify it would be to call it source-path,
and tell people that "." is always prepended when searching for
sources.

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

Great.

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

It's the version in my head :)

s/getdefault/get/

:)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com