Re: [jamboost] Boost.Build projects -- discussion

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
> see.
> 
> 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.
>
> <lib>$(BOOST_ROOT)/whatever 
>
> becomes:
>
> @boost/whatever 
>
> ["@" 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:

@/boost/whatever

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
hierarchy. 

@boost/whatever

would refer to a target relative to the logical project of the current
Jamfile.

[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
>
> @boost/lib/python/libboost_python
>
> one can write something like
>
> @boost/python
>
> 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:

jam libs/python/build

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?

Not afaict

> 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.

That's reassuring! 

-Dave