$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Jeff Garland (jeff_at_[hidden])
Date: 2000-12-11 08:47:46
> At 07:49 AM 12/11/2000 -0500, John Maddock wrote:
>
> >... I don't like the idea of having all the cpp files in one directory -
I agree with this also. However all the .cpp files should be under
boost_top/src/libname.
> >there is no guarentee that all of them will build (not all libraries are
> >supported on all platforms). Nor do I think there should be a single
> >"boost" library build, although I use large parts of boost, I have never
This I disagree with. As I described in my earlier post, this is
inconsistent with current boost header policy. If you don't want a build
which can put all of boost in a single library then we should also move the
headers into their own library specific includes.
> >used all of it in one project, users should not pay for what they don't
> >use, and would prefer to see the boost libraries continue to build as
> >separate libraries. For me that means that putting source in
> ><boost>/libs/libname/src is fine, as long as it is properly documented.
Agreed. I would extend this with a configuration option which allows for
easy subsetting of the library to only the desired libs.
Beman Dawes wrote:
> In addition to his points, consider that boost will almost certainly grow
> far beyond the current size and scope. It will be unmanageable
> if we just
> toss all source files into a single source directory.
Absolutely. And if we make everyone build and link every single library one
at a time they will throw up their hands in frustration. I only link one
library to get I/O streams and STL from the standard library. Of course you
might think this is a bad thing :)
> I can't even count the number of times I've considered using a
> component of
> some library, only to reject it because I had to buy into the whole
> unbounded library just to get the one component. Boost has to figure out
> how to avoid that fate. We don't know the whole answer yet, but keeping
> separate library directories seems likely to be part of the solution.
Agreed. See the suggestion in my earlier post.
Jeff