Re: [boost] Re: Directory Structure

From: Ed Brey (brey_at_[hidden])
Date: 2000-12-15 12:49:08

From: "Jeff Squyres" <jsquyres_at_[hidden]>
> > automagically, you still end up with multiple copies of the same file,
> > which complicates life a bit for the user and the developer.
>
> Why?
>
> The user always uses the installed version.  The [boost] developer (I
> assume that's what you meant) always uses the CVS version, or snapshot
> zip/tarball.

The complication comes in for the combined developer-user, since he makes
changes to one copy of the file but can't use those changes without
copying the file over to the user location.  Sometimes this is desirable,
if the changes are heavy enough to make the library unstable, but often it
is more convenient to always just use the latest and greatest, which
provides subjects the new code to maximal testing.  Having exactly one
copy of any given file allows this with no fuss.

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.

> > I agree this has the potential to be a big plus for the "make install"
> > method, but only if there is true value in the flexability for authors
> > to use directory structures that don't play well with end users
> > #includes.  I don't see where this flexability would be useful.  Can
> > you speculate on any scenarios?
>
> There are many other reasons why there are positive aspects for "make
> install", not just flexibility for library authors.  See my original
post:
> http://www.egroups.com/message/boost/7503.

I looked that over, and the only thing I found that looked specific to
make install was having all files in each library contained under a single
folder, which is the plus tradeoff to be weighed against having exactly
one copy of each file.  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.

> But the point is -- unix system administrators like to install
everything
> in one place when possible.  I don't know how Windows sysadmins tend to
> install things (particularly w.r.t. 3rd party libraries and header
files),
> so the same argument may not apply to the windows world.

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.