Re: Slight Alteration to Boost Directory Structure

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-09 10:32:59

The following message is a courtesy copy of an article
that has been posted to gmane.comp.lib.boost.user as well.

"Simon Bailey <conic_at_[hidden]>" <conic_at_[hidden]> writes:

> --- In Boost-Users_at_[hidden], "Paul Mensonides" <yg-boost-
> users_at_m...> wrote:
>> "William E. Kempf" <wekempf_at_c...> 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_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution