Boost logo

Boost :

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

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

> automagically, you still end up with multiple copies of the same file,
> which complicates life a bit for the user and the developer.


The user always uses the installed version. The [boost] developer (I
assume that's what you meant) always uses the CVS version, or snapshot

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

> > [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"

Boost list run by bdawes at, gregod at, cpdaniel at, john at