From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-12-17 17:10:34
----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
> Currently, targets from other Jamfiles are used by giving the
> location of that Jamfile. There are two ways to move forward that I
> 1. Project names and references
> 1a. References to Jamfile are allowed to point to other projects
> (e.g. to Jamfile with different top-level dir).
> 1b. A syntax for naming projects is invented, and used to
> conveniently refer to jamfiles, e.g.
> ["@" syntax is used here for exposition only, I'll comment on it
> later] For me, this looks like a pure syntantic sugar. If it has
> something else, I'm not aware of that. I don't state that it's not
> needed, but would like the semantics to be agreed upon.
I think it's a way of distinguishing a logical project/target name
from a relative path name. When I first proposed that syntax, the idea
was that everything to the left of '@' is a path name, and everything
to the right of it is a target name. If there's nothing to the left of
'@', the name is expected to be a full logical target name, which
means enough information must have been supplied to find the
target. Actually, I think the above example should be:
The principle being that boost is a top-level project name, so it
should look like it lives at the root of the logical target
would refer to a target relative to the logical project of the current
[Taking the CodeWarrior IDE as an example (Boost.Build aims to be a
text-based IDE), we may need a way to distinguish "I depend on this
other target" from "I depend on this other target, and I need to be
linked to it". On the other hand, I've never used that feature of CW,
so maybe we can forget about it for now]
> 1c. Project/target aliases
> Instead of
> one can write something like
> Looks like syntantic sugar as well.
Clearly. On the other hand, if a user downloads Boost and wants to
build the Python library, it seems a bit perverse to ask her to type:
Don't you think?
> 2. Backward requirements propagation.
> When one uses some library, include pathes should be set to
> something reasonable. It would be a big deal more convenient if it
> can be done automatically:
> exe foo : foo.cpp @boost/regexp ;
> and boost top-level dir appears in includes for foo.cpp ; This might
> be used to affect dynamic library search pathes as well.
I completely agree with this. The only issue is that occasionally it
may be important to control the #include search order. We can cope
with that problem later.
> The questions are:
> 1. Is there anything else about projects support that I've missed?
> 2. Is project naming really syntantic sugar?
Everything beyond machine code is syntactic sugar, so maybe you need
to ask a different question. ;-)
> 3. Can it have a great impact on the overall design or can be easily
> added at a later time.
> I actually meant to make no comment direct comment on the wiki page
> in this message, but one thing is worth mentioning. Namely, it looks
> like David's suggestion to use alternative syntax for naming project
> (as opposed to that for naming Jamfiles) can help a lot with project
> support, and in particular is related to question 3 above.
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