RE: [boost] Directory structure+building boost

From: Jeff Garland (jeff_at_[hidden])
Date: 2000-12-09 12:00:44

> > Is everyone happy about using "/libs/libname/src", or would

No. The /libs really needs to go.

> "/src/libname"
> > be better?

Yes.  See below.

> that depends...  is Boost a single library?

From the current header strategy it seems clear that boost is intended as a
single library.  I infer this since all the headers from the various "micro
libraries" are delivered together.  However, it is currently confusing since
the sub-libraries that build an actual library file are independent.  Below
are some thoughts on how this should be resolved.

From my point of view there are five issues.
1) Consistency
The current scheme is inconsistent.  If boost is a single library at the
header level then it should be so at the library file level.  That is, I
expect to link boost.so not regex.so, pool.so, etc.
2) Minimal dependency
When I build my application I only want to include the libraries I need.
That is, if I only want to use regex, I don't want other libraries taking up
memory or user disk space.  To satisfy this goal I want the ability to
configure the library (on installation) to only include the sub-libraries I
am using.
3) Ease of use and ease of management
The single library scheme is the easiest to manage.  I want to add a single
path to my include options and link a single library.  Building all the
components of the library should be a single command from a single directory
(boost/src) that builds libraries into a single location (boost/lib) with a
single library file (boost.so).  Then there are other options like which
compiler was used, debug or release, static or dynamic which need to be
handled.  My preference is that there this is all handled by naming.  That
is, the stuff in /lib is something like: libboost_gcc_debug.so,
libboost_gcc_release.so, libboost_msvc_debug.a, ...

So I am saying...

boost_1_18_3/boost/      <-- *.hpp files
boost_1_18_3/src/        <-- makefiles to build all of boost
boost_1_18_3/src/regex   <-- *.cpp and makefiles for regex
boost_1_18_3/src/anotherLib
boost_1_18_3/src/...
boost_1_18_3/lib         <-- *.so, *.a files from a build of /src
boost_1_18_3/...

4) Multiple versions simultaneously
Different versions should install in different directories.  When I unpack a
version of boost it should have a top level directory named for the version
and configuration options. For example:

/boost_1_16_0
/boost_1_1_13
/boost_1_1_13_regex_only
/boost_1_1_20_beta

When I am building a project that uses boost, I want to switch in the
version of the library with an environment setting (BOOST_TOP) which defines
BOOST_INCLUDE and BOOST_LIB_PATH.  I'm typically going to have several
versions of boost available simultaneously.  One may support a production
product (perhaps several years old), other versions would be available for
development builds.  Some may be stripped down versions of the library for
projects which only use some small part of the library and need to minimize
footprint (et: embedded system).

5) Beta and pending code
All versions should have the same consistent structure.  Beta versions
contain the beta code (in the normal places not in boost_pending).
boost_pending violates the ease of use tenet.  It requires me to do one of
the following to use pending code: a) change my source includes (Really bad
since when it isn't pending any more I have to change all my code), b)
Complicate my project makefiles (I need to include pending as well as
regular boost in the path, plus one or more libraries), c) move the pending
stuff into the regular boost locations by myself (this is ok, but boost is
growing fast & it would be better if this was just handled by the release
system and the library builders that know the details).

> case then there is some confusion as to what "boost/boost" is to be...

The reason for "boost" is that it allows the source code to reflect the
library structure.  That is I include like this:
//...some file...

#include "boost/cast.hpp"  <-- hint to the reader: this is from the boost
library
#include "rw/thread.h"     <-- hint to the reader: this is from Rogue Wave
library

If the include directory is called "include" then I can't use this coding
scheme.  However, if it is /boost you can say -I.../boost and simply code
#include "cast.hpp".  This would probably be a good thing to include in the
FAQ if there is confusion.

> My *real* preference would be, and I know I am probably going to get
> flaimed for this, to set up the directory structure something like:
>
>   boost-x.y.z/boost  -- containing accepted stuff. implies frozen code!
>   boost-x.y.z/boost/libname.hpp
>   boost-x.y.z/boost/libname/src
>   boost-x.y.z/boost/libname/doc
>   boost-x.y.z/boost/libname/test
>   boost-x.y.z/boost/libname/example
>   ...

No open flame, just a heat lamp.

> Likewise duplicate the same methodology in:
>   boost-x.y.z/boost_pending     -- stuff pending review. implies frozen
> code!
>   boost-x.y.z/boost_development -- stuff being developed and out for
> general play.

Flame thrower locked and loaded :)

Jeff