Re: [boost] Re: Directory Structure

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2000-12-14 18:04:25

On Thu, 14 Dec 2000, Ed Brey wrote:

> 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.

It does not contain the "unity of a library" concept.  i.e., it has files
from a single library in multiple places.  Granted, this is how it is now
already (boost/* vs. libs/*), but from a management point of view (as well
as a new user point of view), it could be desirable to have everything for
one package to exist in a single place.

Going with a "make install" concept would make this point moot; library
authors would be much freer to do what they wanted/needed in their own
directories.  With that concept, only the install tree structure would be
important.

> > One idea that might solve many of the issues being discussed is
> having a
> > "make install" -- the idea of separating the source tree from the
> tree
> > that contains the final .a/.so and .hpp files.  I'll call this
> latter tree
> > 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

I'm not sure that I follow you.  I'm not saying that the number of files
is bad.  I'm saying that that number of files at that level in the file
heirarchy (boost_x.y.z/src or boost_x.y.z/libs or whatever you want to
call it) may be a sub-optimal way to manage those files.

Consider: all the .hpp files have to exist somewhere.  Should they be in
the top level source directory (boost_x.y.z/src)?  Or should they be in
the subdirectory with the rest of each library's files?  In terms of
unity, it seems to make more sense to put everything together.

> install" concept has its uses, but it poses a signficant complexity
> overhead, that if easily avoidable, ought be avoided.

I'm not sure that I agree.  From the user's perspective, installation is
simple:

        % make install prefix=/usr/local
        or
        % ./install.py --prefix=/usr/local

From the library author's perspective, they'll need to supply a list of
files to be installed and where to install them, either in a Makefile or
some secondary text file.

This is a very common approach; it is well understood and documented.

> 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

Sure -- right now.  But what about the future, when everyone in the world
is using boost?  What if some version of boost gets included in a
mainstream Linux distribution?  I should probably say "when", not "if".
:-)

System administrators will need to install all the boost .hpp and .a/.so
files in a central location.  They'll want users to be able to access
boost .hpp and .a/.so files without any extra -I and -L arugments (other
than what they already have to do to get locally installed packages) --
after all, who wants to answer help desk questions about "How do I access
the Boost package?".  If users can access Boost in the same way that they
access everything else, sysadmins, help desk employees, and users will
both be happy.  The world will be a better place.  ;-)

We should not preclude this possibility; I don't think that it's difficult
to do.

> 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.

Sure -- this is exactly what I'm saying.  Right now, boost doesn't have
any infrastructre for this other than telling the user to manually copy
files to their destinations.

Building the .a/.so files is a different (but related) problem that needs
to be tackled as well.

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