"Simon Bailey " writes:

--- In Boost-Users@yahoogroups.com, "Paul Mensonides" wrote:

...

"William E. Kempf" wrote in message

...

That still misses the point. Boost currently won't help you to install the library, but installation certainly wouldn't entail copying the entire $BOOST_ROOT tree to the $INCLUDE directory on your system. You'd only copy the $BOOST_ROOT/boost tree there.

Yes, and this is why I said that it hasn't been a problem for me. However, I see where the OP is coming from as well.

Paul Mensonides

Paul understands me correctly. I confused the issue by making two requests at once.

Mainly, I want to include other libraries alongside boost and provide a single include path. That is the first wish. Bill has pointed out that I could move BOOST_ROOT/boost into my INCLUDE directory. I didn't know that - I thought it might break things.

There are two ways in which it might break things, though they're not problems for all usage models. When Boost.Build v2 reaches completion, it will become possible to set up cross-project build dependencies, so that you can you can make a project which uses a boost library and causes that library to be built automatically when it is needed. It will be important to make sure that Boost's build procedure is immune to having its headers moved. On a similar note, users will want to be able to update their boost tree from CVS with a single update, so separating the headers directory in this way could cause problems. I think both of these issues can be addressed by using a symlink to the $BOOST_ROOT/boost directory in your include/ directory, but of course Windoze doesn't supply real symlinks :(

The second thing I was suggesting (and this is quite minor) was that we make the change to include smart_ptr.hpp (etc.) and thread.hpp (etc.) at the same directory level. I thought that the subdirectories (like /thread) were the way of the future. I didn't realise that the plan was to move all the headers into BOOST_ROOT/boost.

It isn't. I hope nobody said that it was.

So it seems my first wish is not needed and my second wish is already on the drawing board. :-)

I don't think so. The boost header structure is carefully designed so that users who want to minimize include dependencies can use library-specific granular headers in the library subdirectory, but that coarse-grained headers like boost/type_traits.hpp or boost/python.hpp can be easily included from BOOST_ROOT. -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution

Suddenly I remember why I wanted the directory structure change... I could achieve what I want by moving BOOST_ROOT/boost into my INCLUDE directory. But the disadvantage with that is that I need to perform a move operation. *** In my current development environment, my source control directory structure mirrors my release directory structure exactly. *** So, in source control I have: /include --/BOOST_ROOT ----/boost <- headers are here --/my_lib <- headers are here But, in my release I want to have: /include ----/boost <- headers are here ----/my_lib <- headers are here I was suggesting the change so that source control and relase could be the same. This would necessitate that documentation and source for boost would have to be within the boost (include) directory. Some might find that a worse alternative I suppose.