From: Douglas Paul Gregor (gregod_at_[hidden])
Date: 2002-02-28 16:15:15
> > Why would you do this? The versioning "problem" is solved by autoconf
> > and libtool.
> > If someone wants to install multiple boost versions on their system at
> > once, the solution is simple: don't put them under the same prefix.
> That's not a very smooth solution for those who need to test against
> multiple versions. Having a version number under a common prefix really
> simplifies configuration: it means you don't need to explicitly specify an
> installation directory for each version you want to test against.
I think we should weigh the choice between having version numbers under a
common prefix and having different versions under different prefixes by
considering how often each will be used.
Is the average user likely to have multiple versions of Boost in his/her
system? Or perhaps there's a better set of questions:
1) Is the average user likely to have multiple versions of the Boost
headers on his/her system?
2) Is the average user likely to have multiple versions of the Boost
compiler libraries on his/her system?
I believe that #1 is not the case for most users. Boost _generally_ seems
to maintain source-level compatibility between versions, and your system
won't come to a grinding halt if you install new headers and don't
I believe that #2 is much more likely, if Boost is to be used in several
projects. Project A might link against 1.25.1, whereas Project B links
against 1.28.0. Having different directories for the Boost compiled
libraries is a nuisance in this case.
Here's what I'd like from a *nix perspective:
If I go grab version 1.x.y of Boost, build it and install it as root,
I'd like to have easy access to the Boost libraries. Under Unix, this
1) Headers should go straight into $prefix/include/boost, so I can just
#include <boost/foo.hpp> and use Boost. No command-line flags, no hassle.
Versioning the directories (e.g., $prefix/include/boost/1.27.0/boost) is
an annoyance for the few users that don't need mult>iple versions of the
2) Library binaries should go into $prefix/lib and have versioned names,
e.g., $prefix/lib/libboost_regex-1.28.0.so, so that multiple binary
can peacefully coexist.
3) Documentation, jamfiles, etc. can go into $prefix/share/boost. Maybe
the entire Boost source tree can be copied here, and $prefix/share/boost is
just a symlink to $prefix/share/boost/boost?
Final note: often installation can give the ability to specify
include_dir and lib_dir independently. The description I give above could
be the default, but allow more advanced users to customize the directories
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk