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.
>
> -Dave
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
recompile.
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
means that:
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
headers.
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
versions
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
used.
Doug