Re: [boost] Re: Directory Structure

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2000-12-15 12:50:43

On Fri, 15 Dec 2000, John (EBo) David wrote:

> [snipped: reduction to...]
>
> #include <libname1.hpp>
>
> [snipped: vs...]
>
> #include <boost/libname1.hpp>

I think we all agree that the latter is preferable, for include filename
clashing reasons.

> Ok. we *could* have the above directory structure and just install it
> first, and then use it right?  Well...
>
> Now here is where it starts to get a little subtle.  If we break the
> library up into boost-1.19.0/libnane2/src/... and use an boost
> directory to hold the installed include files such that we can use
> #include <boost/libname1.hpp> in our code.  We would probably find
> that libnane2 depends on libnane1 being built AND installed before it
> can find it.  Worse yet, I can see building things piecewise and
> forgetting to install the new version of libname1 and building the new
> libname2 against the older one without knowing it.

This is an excellent point, and care would need to be taken to allow boost
developers to be able to use the CVS tree to compile/test/develop *and* to
allow regular users to compile/develop with the installed tree.
Specifically, the design of boost should not exclude either possibility.

It is definitely true that moving the .hpp files back into each library
subdirectory would necessitate more -I's for the boost developer.  Keeping
the <boost/foo.hpp> nomenclature is certainly do-able, though:

boost_x.y.z/
  src/
    regex/
      boost/
        regex.hpp
      src/
        src1.cpp
        src2.cpp

So the boost developer would need -I$top/boost_x.y.z/src/regex, and then

        #include <boost/regex.hpp>

would still work.  However, an additional -I would be necessary for every
boost sub library that you wanted to use.  Icky, annoying to type, and
prone to mistakes (because, assumedly, there will be lots of -I's that
you'll need).

One solution for this is the "wrapper compiler" concept.  In a different
library community -- parallel programming with the Message Passing
Interface (MPI) -- every implementation of the MPI spec provides a
"wrapper compiler" that is just a script or short program that
automatically inserts the correct -I, -L, and -l arguments for the user.
The user uses this wrapper compiler just like a normal compiler -- all of
their arguments are passed down to the real compiler.  For example:

        boostCC myprogram.cpp -o myprogram

turns around and executes:

        CC -I/usr/local/include myprogram.cpp -L/usr/local/lib \
                -lboost_regex -o myprogram

I used unix syntax here, but the same concepts apply to windows and
others.  This concept has proven to be extremely useful in the MPI
community; since MPI is a library, using "mpicc" can hide all the
complexity of -I, -L, and -l arguments from the user, and even give a
more-or-less platform independant way of compiling MPI programs.

I asked in a post a few minutes ago if python exists on all platforms that
it is desirable to use boost on; if so, this would make a wrapper compiler
fairly easy to implement.

> Now for installation.  When installing we could set it up to install
> sellected components or the whole thing at a time.  ex:
>
>   make install-libname1
>   make install-libname2
>
>      or
>
>   make install-all

This makes me thing about something Beman said in a previous post --
several of the boost core libraries all depend on each other.  And some of
the non-core boost libraries depend on one or two of the core libraries.
You can easily imagine a dependency graph here.

Should the build/install infrastructure enforce this, and protect the user
from themselves?  i.e., if you did:

        make install-libname1

should it fail with an error indicating that libname1 also depends on
libname2, libname3, etc.?  Or automagically install libname2, libname3,
etc.?

Installing piecemeal can be problematic; there should either be some
protection for naieve users or it should not be allowed, IMHO.

{+} Jeff Squyres
{+} squyres_at_[hidden]
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to ND for 4 years and ended up staying for a decade"