Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk