From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-07-15 02:20:08
Mark Elston 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
> > to a file, otherwise it refers to target.
Oops, there's a thino. This should be the other way around: if there is "//",
reference is to a target, otherwise it's to a file.
> > 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)?
Nope, it really refers to target "ghi" in project "abc/def".
> > 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.
Actually, we used to have different syntax some time ago, which was:
where target name could not include slashes. We dropped "@", because (IIRC),
it was of no use.... Hmm.... I'd really don't want to switch syntaxes like
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