Re: [boost] Re: Directory Structure

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2000-12-16 11:06:48

On Sat, 16 Dec 2000, John Maddock wrote:

> >My experience in this regard was with STLport, which I intended to just
> >use, but I ended up having to put on the developer hat a little bit in the
> >version 4 beta days, which meant experimenting with code changes so I
> >could submit meaningful bug reports.  It was nice to have the simplicity
> >of a single copy of the files to work with.
>
> Agreed 100%:  KISS again.

A single copy is nice, but you're not going to find too many sysadmins who
are going to be willing to unzip the boost distribution inside /usr/local.
They would be much more comfortable expanding and building boost in a
separate tree and doing a separate "make install" process that they were
confident only installs into common places (e.g., $prefix/lib,
$prefix/include).

Yes, this is probably different than
user-who-downloads-to-their-Windows-workstation model -- but it's the same
for *any* OS that has a distributed filesystem with shared resources
(Windows/Mac included).  When you start installing something outside of
your own $HOME directory and make it available for multiple users to use,
it's a different ballgame.

Boost should *not* limit itself to the idea of single-user installations.

KISS is good, and definitely a sanity check.  But some jobs have
sophisticated requirements, and therefore require more sophisticated
answers -- not everything can be simple.  Look at the depth and breadth of
the discussions on this list about the C++ code in boost -- these are
*not* simple answers.  But they are Good, and Right, and all other Jargon
terms for fundamentally sound problem solving.

Don't get me wrong; Boost certainly doesn't have sophisticated
installation requirements.  It's essentially just copy a few files, and
possibly run ranlib.  But this is non-trivial... more to the point, it's a
nonzero effort to do *properly*, especially for multi-user installations.
It is common to have some kind of installer tool for software packages (in
any OS).  Unix freeware stuff tends to use the "./configure ; make all
install" model.  Windows typically have a "setup.exe" or "install.exe"
kind of model.  Mac has similar installers.

From another standpoint -- what's simpler (KISS) from the perspective of
the common user:

- Both schemes (use install tree vs. use distribution) have a single -I
  (unless, of course, .hpp files moved back into the library
  subdirectories... :-).

- Install scheme uses a single -L to get to all boost .a/.so's,
  distribution scheme uses multiple -L's to get to each boost .a/.so.

- Install scheme can piggyback on central resources that are already
  available (e.g., all other local packages are already installed to a
  central location).  Hence, a single -L gives a user access to boost,
  GTK, Tcl/Tk, etc.  Distribution scheme forces the use of not only
  multiple -L's within boost, but also guarantees that boost won't be
  located in the same place as any other package.

Since I entered the list (thread "New Boost User", 3 months ago), my main
contribution has been "simplicity for the common user".  "Common user" is
defined as someone who just wants to download a boost installation,
install it (whatever that means), and *just use it*.  They don't care
about development, etc.

I think that making life easier for the common user (perhaps at a slight
cost to the boost developer) can only benefit boost by making it more
popular and more widely used.

I'll get off my soap box now.  :-)

> >The other things you mention, like having a single
> >source tree allow compilation for multiple platforms are good ideas, but
> >don't seem to hinge on a "make install" scenario that copies source files.
> >All that is needed is a make process that has differing destination
> >directories for each platform, and a way for each compiler to see the
> >headers and libraries.  Copying isn't required here, since symlinks and
> >environment variables can do the job.
>
> Also agreed 100%

I think the key phrase here is "...and a way for each compiler to see the
headers and libraries."  I'm restating myself, but having a common
location for all local packages to be installed (i.e., not just boost)
means that you only have to tell your compiler *one* location to go to get
all of them.

I'll take a Unix example (certainly applies to the different compilers
scenario under Windows, too).  It's not uncommon for system administrators
to have a networked filesystem with shared resources on it.  A typical
setup could be something like this:

shared/				- top-level exported directory
  sparc-sun-solaris2.7/		- tree for Solaris 2.7
    bin/
    include/
    lib/
  i686-pc-linux-gnu/		- tree for Linux on x86
    bin/
    include/
    lib/
  // ...more architecture/OS combinations...

Solaris machines can locally mount shared/sparc-sun-solaris2.7 on
/usr/enterprise, while Linux machines can locally mount
shared/i686-pc-linux-gnu on /usr/enterprise.

Hence, users *always* use -I/usr/enterprise/include and
-L/usr/enterprise/lib to get to all enterprise-installed-wide resources,
regardless of architecture.  And if a user wants to explicitly get a
specific tree (e.g., the Windows scenario for different compilers), that
is certainly possible (and easy) as well.

This is very simple for users to understand and use.

Having multiple object trees in the boost distribution tree does not allow
system administrators to leverage a scheme such as the one outlined above;
it is still a single-user-installation view.

Indeed, having an install scheme allows the flexibility to to *both*: you
can install to /shared/sparc-sun-solaris2.7, or you can install to the
tree where you unpacked the boost distribution (and effectively have the
different object trees scheme mentioned previously).

Hence, I claim that having multiple object trees in the boost distribution
tree is a special case of a more generalized scheme.

> >An example of existing practice in the Windows world is Microsoft's
> >Platform SDK.  It installs completely in its own directory, without
> >touching the compiler's directory structure.  Include paths are used to
> >hook into header.  The same goes for STLport.  This scheme used by these
> >tools provide some benefits: Allows SDK to be used by multiple
> >languages/compilers; easy to uninstall; easier to see what to blame when
> >something doesn't work.
>
> And again 100%.

I think we agree here:

1. Don't touch the compiler.  It's a Bad Idea to install headers/libraries
into the compiler's tree.

2. Switching between multiple versions (e.g., for different compilers)
should be easy.  Simple -I and -L args should do everything.

3. A *clean uninstall* should also be easy.  This is *very* important.
Once an install tool is made, making the inverse of that should be fairly
easy.

One subtle difference that we may be disagreeing upon: I don't think that
most users will want to frequently switch between boost versions.  i.e.,
they'd be happy to overlay their old boost distribution with a new one and
just exclusively use the new one.  Boost developers, certainly, will want
the ability to switch back and forth easily; nothing mentioned above
precludes this possibility.

> One other point that came across from a point made by Beman in a
> private email on another subject - some commertial users will simply
> not use boost if it relies on any tools not installed by default on
> the target platform - that means no python among other things - sorry
> :-(

Does this mean that they don't want to rely upon having a C++ compiler
installed?  ;-)  (sorry, couldn't resist)

I believe that there are alternatives.  Shell scripting languages are
installed on every unix platform.  There must be some scripting languages
available on Windows and Mac (not being a developer on these platforms,
however, I don't know), or some other kind of tool that can be used for
this purpose.  Installation is a common activity; there must be some kind
of tool that we can leverage on platforms that don't have native scripting
languages.

Heck, we could even write a short C++ program to install boost that is
built as part of the default build!  ;-)

So perhaps the first task is to identify the tools that will be used on
each platform.  And then come up with a way to not have to maintain
separate installation procedures on each platform; i.e., a unified way to
feed each of the installation tools on their respective platforms.

{+} Jeff Squyres
{+} squyres_at_[hidden]
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to ND for 4 years and ended up staying for a decade"