From: David Abrahams (dave_at_[hidden])
Date: 2004-07-15 08:17:14
Vladimir Prus <ghost_at_[hidden]> writes:
> David Abrahams wrote:
>> Why don't you write up the summary again with the correction and we
>> can look at it afresh?
> Here it goes:
> 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 refers
> to a target, otherwise it refers to a file
> 1 Target reference which refers to file is interpreted as file name relative
> to the source directory of the project where target reference is used.
> 2. Target reference which refers to target constists of two parts. The part
> after "//" names a target in Jamfile. The part before "//" identifies a
> 2.1 2.1 The name of a target should be exactly the name specified in
> project referred by the part before "//"
When you say "specified" you mean "by calling the 'project' rule" as
> 2.2. The part before "//" can identify a project in two ways: by specifying
> directory of Jamfile, or by specifying symbolic project id. 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.
> Project ids are assigned by calling the 'project' rule in Jamfile, passing the
> project id as the first argument. The project ids are always absolute,
> e.g. /boost/python
It's beginning to look comprehensible, though not yet ideal.
>> Then the leading slash is redundant :(
> Yea. The question is if we want to just remove the leading slash, or allow
> relative project ids. The latter approach seems better -- while I never
> lacked relative ids much they would make the syntax more "complete".
A possible problem is that if you allow relative project ids you then
have no way to explicitly refer to a Jamfile via a path in the
filesystem that happens to match a project id.
>> >> > I hope I've specified everything. If not, let me know and I'll
>> >> > fill the holes.
>> >> How do project ids get assigned?
>> > It's assigned when Jamfile calls the 'project' rule. The id passed
>> > to the 'project' rule should be always absolute.
>> Seems like it makes more work in explicitly specifying project ids
>> than it should have to, and allows for possibly-confusing errors, like
>> a sub-project of /boost named /boast/foo
> We sure can make declaring ids relative to parent work. I might do it rather
> quickly if we decide it's needed (though I might decide to refactor
> project.jam at the same time)
I'm trying to suggest that projects should never have to declare
their own ids. That will make it much easier to write portable and
> OTOH, in either case 'use-project' would need full id if you want to refer to
> specific project.
> use-project /boost/python : some-path
Not if you had
use-project /boost : some-path ;
and in boost's Jamfile some mechanism like:
locate-subprojects libs/\\1/build \\1 ;
There are several advantages here:
for one, there's no need to work around top-level project id
conflicts, because each project establishes its own notion of where
other top-level projects are.
for another, much less maintenance when new projects are
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
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