From: Mark Elston (m.elston_at_[hidden])
Date: 2004-07-14 14:24:56
> -----Original Message-----
> From: Vladimir Prus
> Sent: Wednesday, July 14, 2004 8:22 AM
> To: jamboost_at_[hidden]
> Subject: Re: [jamboost] Re: target references
> David Abrahams wrote:
> > > 1. Target-id is either file or target in Jamfile
> > > 2. If it's target in Jamfile, it can be in the current Jamfile, or
> > > elsewhere 3. If it's elsewhere, we can use either filesystem path to
> > > refer to location of other Jamfile, or its symbolic project id
> > That's only half the summary. You haven't described how the syntax
> > is interpreted to yield those semantics (except in a bunch of
> > incomplete fragments from prior messages). Gather it all in one
> > place so we can look at it.
> 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
> to a file, otherwise it refers to target.
> 1 Target reference which refers to file is interpreted as file name
> to the source directory of the project where target reference is used.
So if I have a reference like 'abc/def//ghi' this refers to file 'ghi' in
*current* directory (where the reference is *used*) instead of in the source
directory of project 'abc/def' (where the project is defined)?
> 2. Target reference which refers to target constists of two parts. The
> after "//" names a target in Jamfile. The part before "//" identifies a
Wait a minute. I thought you said in '0' that if a target reference has
in it then it refers to a file. Now it refers to a target in a Jamfile as
In '0' you implied it refers to a target if it does *not* have a '//' in it.
I don't get it.
> 2.1 The name of a target should be exactly the name specified in Jamfile.
> 2.2. The part before "//" can identify a project in two ways: by
> 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.
This, I think, is the rub. Sure, the build system can make a clear
determination by looking for the ID then looking for the path. However, I
think that the problem is that users will be trying to read this and would
like a little visual distinction between the two. Otherwise, users would
to read every Jamfile in an entire build tree to find out whether or not a
target reference referred to a project id or a path.
Is that your point, David?
I don't know if your answers helped David or not but they added to my
confusion. Sorry. :(
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk