Re: [boost] Re: Directory Structure

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2000-12-15 12:10:56

On Thu, 14 Dec 2000, Ed Brey wrote:

> > already (boost/* vs. libs/*), but from a management point of view (as
> well
> > as a new user point of view), it could be desirable to have everything
> for
> > one package to exist in a single place.
>
> I agree that having each library completely contained within a
> subdirectory is a good thing.  The difficult question is whether that
> good thing better than not having to copy any source files around,
> which is also a good thing.  Even if the copying is done

I think it's more of a question as to whether to subscribe to an "install"
process or not.  Every OS has common install methodoligies -- source code
packages in the Unix world typically have "./configure; make all install",
Windows packages have some form of automated copy, either from a
distribution installer, or from a CD or something like that (where you get
asked the inveitable "Where do you want to install this?  C:\Program
Files\blah".

So yes, extra copying is done.  But it's the infrastructure's
responsbility to handle the installation location independence, not the
user's.

> 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.

> > Going with a "make install" concept would make this point moot; library
> > authors would be much freer to do what they wanted/needed in their own
> > directories.  With that concept, only the install tree structure would
> be
> > important.
>
> 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.

> > [snipped plug for boost world domination]
>
> This would definately be nice.  I'm not up on my Linux compilation
> environment.  Is it easy to tack on another include directory to the
> default include path, so that g++ knows to look by default in
> /usr/local/boost_xyz for include files, or is the only way to get a
> default to copy the include files into /usr/include/boost.

Er... maybe.  Probably.  I have no idea.  I certainly wouldn't want to go
mucking around in gcc's internal support files to find where the list of
default -I directories is.  Indeed, what if you RPM (or otherwise) in a
new version of the compiler (same concept applies in Windows)?  You'd have
to go re-muck around to set this default list.

Linux distros, for example, tend to install everything under /usr -- so
users can do a single -I and -L to get "everything".  Other flavors of
Unix tend to not come with many open source packages, so system
administrators tend to install things under /usr/local or some other
"global" directory.

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.

{+} 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"