From: Ed Brey (brey_at_[hidden])
Date: 2000-12-14 10:04:32
From: "Jeff Squyres" <jsquyres_at_[hidden]>
> However, there is one issue that I disagree with: having library
> files in the top-level boost directory. Having single .hpp files
> entire library is not a bad idea (I won't take sides here; this is a
> separate issue) -- I think that having them all in the top-level
> is not Good. Jens pointed out that this will grow to be
unmanageable -- I
> agree; this does not seem to be suitable for the top-level
> directory, especially since Beman has pointed out that he expects
> grow much larger than it currently is.
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.
> One idea that might solve many of the issues being discussed is
> "make install" -- the idea of separating the source tree from the
> that contains the final .a/.so and .hpp files. I'll call this
> the "install" tree.
Consider the trade-off: 2*N directory entries versus 2 to 3 copies of
various states of the boost build. I don't dispute that the "make
install" concept has its uses, but it poses a signficant complexity
overhead, that if easily avoidable, ought be avoided.
The common case is for a user to download boost, run make to generate
a library for a single platform, or to include the implementation
files directly in his own project. For this a single tree is easily
sufficient for both working with headers and implementation. The
source tree structure is independent of how the tree gets built and
where the generated files go. E.g., multiplatform compilation is just
a matter of providing destinations for the generated files that are
based on the platform name.
Overall, IMHO, Lois's suggestion is excellent.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk