From: David Abrahams (dave_at_[hidden])
Date: 2004-07-15 06:25:59
Vladimir Prus <ghost_at_[hidden]> writes:
> David Abrahams 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 refers to a file, otherwise it refers to target.
>> ?? Seriously ??
>> The standard syntax everyone knows for referring to files, a path with
>> no "//"s in it, always refers to a non-file, and to refer to a file
>> you have to use the funky new syntax that uses "//"??
>> _That_, my friend, is counterintuitive [not to mention the notion of
>> "a target reference that doesn't refer to a target", but I can live
>> with that one for now]
> Alas :-( As I've said in another email, I wrote that backward -- if there's
> '//', it refers to a file.
Why don't you write up the summary again with the correction and we
can look at it afresh?
>> > 2.1 The name of a target should be exactly the name specified in
>> > Jamfile.
>> Which Jamfile, and how is it specified?
> Another wording:
> 2.1 The name of a target should be exactly the name specified in
> project referred by the part before "//"
>> > 2.2. The part before "//" can identify a project in two ways: by
>> > specifying 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.
>> So project ids are always absolute?
Then the leading slash is redundant :(
>> > 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
...but at least I understand it.
>> > Ok, I understand. I wonder though, why nobody complained about it
>> > yet....
>> Your userbase is those people willing to live on the bleeding edge
>> using pre-release software. Just because they're not complaining
>> about lack of explicitness and comprehensibility doesn't mean the
>> interface and documentation will pass muster with the rest of the
> I see. But those users sent a lot of complaints in other areas, so
> I'm not sure they'd not mention target id is they were very
People who "just want to get something done" will accept and
repeatedly apply a pattern without really understanding it. Not
everyone can work that way... especially if they're trying to write
documentation ;-). I hope you agree that someone needs to write the
rules down in the docs. If the rules are too complicated to
understand, the docs will confuse people.
> Anyway, what I'm really trying to do (besides deciding on the right
> syntax), is avoid asking the users to update Jamfiles once again, so
> probably we need to support existing syntax (maybe even without
> docs) for quite some time.
Yes, I was thinking the same thing. We could probably add a
command-line option that updates Jamfiles automatically ;-)
>> >> I don't. How do I refer to the boost/python project from a
>> >> project unrelated to Boost?
>> > You start by saying
>> > use-project /boost : path-to-boost ;
>> > after that, top-level Boost Jamfile is loaded and in turns loads
>> > Boost.Python Jamfile, which registers the "/boost/python" id.
>> So boost has to explicitly load the Jamfiles of any sub-projects that
>> are to be found relative to its project ID? I find that bad from a
>> maintenance POV.
> In some sense you need to somehow refer to all sub-projects from top-level
> Jamfile. For example, when installing you need the list of all libraries. In
> V1, that list is computed via GLOB magic -- which V2 can do as well -- but we
> still need the list of all libraries. And we we have it, we can load
I understand... but do you think that's a good idea? If there were
some rules for searching based on project path it would reduce the
burden of project maintenance and the chance of error.
>> One of your original goals for sub-projects, IIRC, was that they be
>> composable into new project hierarchies. That means the boost/python
>> sub-project shouldn't be forced to know its own absolute project ID.
> I don't think I planned that you can take any project -- like
> python, and move it into different project without also moving
> top-level Boost Jamfile.
Maybe it was Ali. I distinctly remember discussing the idea that an
existing "top-level" project could be moved into another project as a
> In fact, because some requirements are inherited from Boost Jamfile,
> moving one project is not possible.
Maybe not in the case of Boost, but perhaps in general?
> Likewise, I did not plan that -- or rather, did not though -- about
> renaming top-level project and automatically renaming all the
> What I surely did want was specifying project-id relative to parent's
> project-id, so that
> project /boost/python ;
> project python ;
> That never was implemented, though I don't know why -- now it seems
> straight-forward task.
Right now a top-level project needs to name each of its subprojects,
and each subproject needs to name itself. I think it would be
valuable to reduce the amount of redundancy in the system.
-- 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