[boost] Re: Directory Structure

From: John Maddock (John_Maddock_at_[hidden])
Date: 2000-12-13 08:20:24

>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
(although I would accept that the choice of "/libs" for the directory name
was an unfortunate one).  Any major reorganisation is also a major PITA
from the cvs / maintenance point of view, although I accept that it is
better to do it sooner rather than later if we must do it.

>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
libraries have a single large header for "everything", with possibly
smaller headers for subsets.

For example regex has:

boost/regex.hpp   //everything
boost/cregex.hpp // C-interfaces for C++ builds
boost/regex.h        // C interfaces for C builds
boost/pattern_except.hpp  // exception classes (possibly reused by future
pattern matching algos)
boost/regex_traits.hpp  // traits classes (possibly reused by future
pattern matching algos)

>Besides convenience, having a single header for each library has another
>advantage: it isolates the user from any subsequent changes in the
>directory structure, or other organizational considerations. And it
>makes it easy to test against multiple versions of the library, simply
>by changing the argument to -I.

Again isn't that the case now, provided differing boost versions are
installed in differing directories (boost-1.1.9 etc).

>As libraries are added to boost or evolve within it, the only
>integration effort necessary should be updating index.html. Each library
>author provides the single header for the top level, plus the tree that
>goes below it, with a makefile which conforms to the pattern, of course.
>If that library is divided into sub-components that complicate the tree,
>it's up to the library author to handle the situation locally. 

Again that's the case now - provided you don't mind the choice of /libs as
a directory name.

>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
for example there are 6 different runtime libraries, and therefore 6
different regex libraries get built (one for each runtime), it is
absolutely vital that the regex library that gets linked in matches the
runtime library selected in the users IDE options - that's why library
selection is automatic via header file selection (cf STLPort which does the
same thing) - without this mismatched library selections lead to runtime
crashes that are very very hard to track down (you wouldn't believe how
many really intelligent people get caught out by this otherwise).

Anyone know if the Software carpentry people have considered these kinds of
issues?

> Each makefile starts by including this config file,
>which contains not just CFLAGS but COMPILER_NAME, the target LIBNAME,
>possible DEBUG_OPTIONS, MULTITHREAD_OPTIONS, LINKER_ARGS, and so forth.
>The makefiles just concatenate these macros to build a command line.

Not all make's are created equal (Borland's can't handle makefile includes
as far as I know), not all compilers use the same command line options,
even for things like setting the output executable name:

most unix compilers use: -o exe_filename
Borland uses:                      -eexe_filename      # note no space!

Having said that, if you can get it to work, good on you!! :-)

I'm sorry if this seems negative, it's not meant to be, I'm just happy with
what we have, accepting that "libs" was not an ideal name choice (although
I don't know what would replace it, so maybe it's as good as anything).

- John.