Re: [boost] Re: Directory Structure

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2000-12-15 19:04:05

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

> > [snipped dir layout with .../src/regex/boost/regex.hpp and MPI
> >  wrapper compiler discussion]
>
> For development that is fine, but I would still like to see installs
> into a single install tree so that I would not have to explain (and
> maintain) an additional compiler wrapper unless absolutely necessary.
>
> Another way to do this is with a shell script that reports
> configureation parameters.  Examples of this is the ImageMagick studio
> and GTK
>
> [snipped explanation of config flag script]

Ah yes -- this is another way to do it.  I kinda like the wrapper compiler
approach (seems a bit more elegant), but there are a few cases where the
config flag script idea is more flexible and/or necessary.

Either would be fine by me.

And I fully agree that this should be a boost developer tool -- while the
MPI world has generally come to accept "just use mpicc to compile your
code", it did take a critical mass of user base to finally understand and
accept that, and we still periodically get newbie questions about where
libmpi.a/.so can be found.  :-)

> > > [snim: make install and libname...]
> >
> > 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.

(sidenote: pardon my misuse of termiology in the above discussion, Beman's
choice of terminology is much better than mine)

> If it were up to me ;-) I would probably do both and install a
> libboost.a/.so (or boost.dll) and all the little libregx.a/.so...

Another sidenote: I still vote for libbost_regex.a.  Just like we can't
risk a collision in the include filename namespace (#include <regex.hpp>),
we can't risk a collision in the library filename namespace, either.

And the scoping mechanism is a bit different for libraries -- you can't
-lboost/regex, for example, like you can do with header files
<boost/regex.hpp>.  Hence, "boost" has to become part of the library
filename itself, such as libbost_regex.a/.so.

> For the naieve users, and those who do not care to strip it all down,
> have them just include -lboost or boost.dll.  Including each small one

Amen, brother!  I couldn't agree more; make the common case easy.  :-)

> is noted for advanced users only, but for those of you who want/need
> it, we make it availible to you.  If you want to include each one
> seperately for some reason then you need to deal with the dependencies
> yourself... and it is the responsibility of the advanced user.

I think we could still make some kind of niceness of boost developers in
terms of getting an individual library or subset of libraries.  Perhaps
this can be restricted to builds within the CVS [read: development] tree
-- perhaps some command line option(s) to a wrapper compiler/config flag
script?

> > Installing piecemeal can be problematic; there should either be some
> > protection for naieve users or it should not be allowed, IMHO.
>
> true, but that is 1) for advanced users, and 2) we could set it up to
> install all dependcies or possibly set up an option that warns that
> there are unresolved depencies and give them yet another option that
> installs all of the dependencies too like:
> install-libname1-dependencies.

Agreed.

{+} 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"