RE: [boost] Re: Directory Structure

From: Jeff Garland (jeff_at_[hidden])
Date: 2000-12-14 07:24:39

I am in agreement with Lois's directory suggestion.  It is that same as what
I was after, but more concise since it removes the /src under BOOST_TOP.

> >How about this as a directory structure:<
>
> While I see where you're coming from, it's essentially the same as the
> current structure, with boost/ replacing libs/.
>
> It has the disadvantage that library specific headers end up in
> boost/libname, alongside licence files, readme files and other misc
> top-level stuff.  IMO the current structure is better in this respect

Why can't we reserve boost/libname for the actual code and push all the
stuff you mention into boost/libname/doc?

> >The top-level boost directory contains a _single header_ for each
> >library, which provides all the declarations necessary to use that
> >library:
>
> With the possible exception of the graph library (which IMO is so large it
> has to be split up), isn't this more or less the case already?  Most

Not quite.  If we really follow through on the suggestion some libraries
would need to be changed.  For example, smart_ptr.hpp should include 4 files
from boost/smart_ptr: scoped_ptr.hpp, scoped_array.hpp, shared_ptr.hpp and
shared_array.hpp.  Or if I want (and I would like to), I could include the
individual files directly from boost/smart_ptr.  Right now I can't just
include scoped_ptr.hpp because scoped_ptr is lumped together with shared_ptr
into smart_ptr.hpp.  I am also in favor of the *_fwd.hpp file for complex
libs as well.

> >it should be possible to create a single Makefile template which can
> >cope with the various options we're talking about.
>
> I'm not sure that that is the case - maybe for simple unix builds yes, but
> for anything complex I don't see how.  For example in the regex
> library the
> makefiles for VC6, Borland C++ and gcc are very different (although all
> generated automatically from a simple script "makefile_gen" - this could
> maybe be extended boost-wide if required).  To take the Borland compiler

I sincerely hope that Lois has time to provide some example makefiles.
While I agree with John that it is not simple due to all the variations in
make systems, it is something that needs to be done.  I suspect that a good
bit of ground could be covered by providing a set of gmake compatible files
since gmake is free and widely available.  Makefile generation tools (ala
John's script or Imake) would be good options as well.

Jeff