Re: [boost] Re: Directory Structure

From: Ed Brey (brey_at_[hidden])
Date: 2000-12-14 19:27:28

From: "Jeff Squyres" <jsquyres_at_[hidden]>
>
> > IIUC, Lois' proposal involves two directory entries per library at the
> > level under "boost".  I fail to see there 2*N entries is considered
> > unmanageable.  N*log(N) or even 5*N, I could see, but just twice the
> > number of libraries?  If so, that means that just the minimum of N
> > directories, by defintion, would be semi-unmanageable.
>
> It does not contain the "unity of a library" concept.  i.e., it has
files
> from a single library in multiple places.  Granted, this is how it is
now
> 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 automagically, you still
end up with multiple copies of the same file, which complicates life a bit
for the user and the developer.

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

> System administrators will need to install all the boost .hpp and .a/.so
> files in a central location.  They'll want users to be able to access
> boost .hpp and .a/.so files without any extra -I and -L arugments (other
> than what they already have to do to get locally installed packages) --
> after all, who wants to answer help desk questions about "How do I
access
> the Boost package?".  If users can access Boost in the same way that
they
> access everything else, sysadmins, help desk employees, and users will
> both be happy.  The world will be a better place.  ;-)

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.