Boost.Build projects -- discussion

From: Vladimir Prus (ghost_at_[hidden])
Date: 2001-12-17 12:05:08

There was a discussion about projects semantics at 
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Build_Projects. 
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).
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.
1c. Project/target aliases
Instead of
@boost/lib/python/libboost_python
one can write something like
@boost/python
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 
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.

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.

- Volodya