Installing Boost (WAS: Re: [boost] Re: Why Jam?)

From: danl_miller (danl_miller_at_[hidden])
Date: 2002-02-28 10:46:01

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 11:54 AM 2/24/2002, Rene Rivera wrote:
> 
>  >There has been some discussion before as to what installing Boost
should
>  >be,
>  >and that is what we seem to want to discuss now. Question is, as a
"Boost
>  >user" what do think a Boost install should do?
> 
> Rene,
> 
> This is probably a naive view, but shouldn't Boost install do
whatever is 
> necessary to make it look like Boost is part of the compiler
supplied 
> object library set?  (Even better if it can also make the Boost
headers 
> look like they were part of the compiler supplied header set.)
> 
> --Beman

  Colocating Boost libraries with compiler-supplied libraries (and
colocating Boost headers with compiler-supplied headers) would be
problematic.

  [ "THE" COMPILER ]

  The concept of "the" compiler itself has some problems.  Often on a
given network (e.g., my employer's Sun network) there can be multiple
vendors' compilers installed (e.g., Sun Forte/Workshop, GNU GCC) which
undermines the concept of a single compiler.  Furthermore, on a given
network there can be multiple versions of a single vendor's compiler
installed (e.g., Sun Forte/Workshop 4.2, 5.0, and 6.0) which further
undermines the concept of a single compiler.

  So considering m vendors' compilers where n versions each are
installed, there can be mn compilers installed, which erodes the
concept of a single "the" compiler.  Let us assume that instead of
"the" compiler, we reword as "each" compiler.  That means that Boost
would be installed mn times (once for each of the mn compilers) when
one installation could have sufficed.  This can be considered an
on-going maintenance problem where one compiler's Boost is updated,
but not others.  (Obviously installing Boost within one compiler's
directories and having other compiler's reference that one
installation is unwise due to intermixing of nonBoost
compiler-supplied headers & libraries with a compiler for which they
were not intended.)  Instead, Boost libraries should be installed once
in a single default directory-tree which can be shared by all
installed compilers of differing vendors & releases.

  To have multiple revisions of multiple vendors' compilers all using
a
single central installation of Boost would require that portability
tuning of #defines are decomposable on a per-vendor (and optionally
per-release) basis.  Having a single file with a single nondecomposed
monolithic list of tunable portability conditional-compilation macros
would prohibit such inter-vendor & inter-release sharing of a single
installation of Boost by multiple vendors and/or multiple releases of
compilers.

 
  [ JURISDICTION ]

  Often in a corporate environment, a central
information-systems/system-administrator group maintains the servers
in computer rooms (including restrictions on root access and physical
access).  The IS/admin group often installs the compilers which are
shared by multiple development groups throughout the corporation. Each
far-flung development group is separate from the IS/admin group.  The
IS/admin group provides a central administrative/support benefit to
the numerous development groups.  The IS/admin group ensures that
well-maintained compilers & servers & licenses are provided for the
numerous development groups who are free to focus only on the
development of their software product for sale.  If one development
group wants/needs to use Boost 1.27 (and thus wants to see only Boost
1.27), but another development group wants/needs to use Boost 1.18
(and thus wants to see only Boost 1.18), and still another development
group rejects certain Boost libraries in favor of competitors (and
does not want to see those certain Boost libraries at all), then the
central IS/admin group is in an awkward position if Boost headers &
libraries are colocated & intermingled with each compiler's headers &
libraries, respectively.  Instead, Boost libraries should be placed in
a default directory-tree which can be administered (by different
groups of people) separately from each compiler's directory-tree.

Indeed, with the assistance of a
configuration-management/revision-control system, Boost could be
installed to a single directory location, but along different branches
so that each separate development group can control their own internal
affairs without interference from other development groups.

  [ PRESUMPTION ]

  Colocating Boost with each compiler's header & libraries is
presumptuous that Boost libraries (i.e., the current inventory and the
current state of each library) are likely to be eventually be
incorporated into some future release of each compiler.  The way that
Boost libraries would be incorporated into the release of each
compiler would be adoption as part of C++0x or some other standard
with which the compiler vendors were compelled to comply.  (Even then
the namespace would likely not be boost, but rather std or
equivalent.) 
Until & if any Boost libraries are adopted by C++0x or some other
standard, then and only then should Boost libraries be colocated in
such a normative way with each complier. (But then they would, quite
honestly, not be Boost libraries with today's content in boost
namespace, they would be standard libraries with evolved content in
some other namespace.)