From: Vladimir Prus (ghost_at_[hidden])
Date: 2001-12-17 12:05:08
There was a discussion about projects semantics at
It was decided to move it to the jamboost mailing list, and so here I am.
However, since I've already used words like "maze" in that discussion and
what is proposed has became somewhat compicated, I'd like to go back a little
and discuss what the meaning of projects is.
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).
A syntax for naming projects is invented, and used to conveniently refer to
["@" 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.
1c. Project/target aliases
one can write something like
Looks like syntantic sugar as well.
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
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.
The questions are:
1. Is there anything else about projects support that I've missed?
2. Is project naming really syntantic sugar?
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