Re: [boost] boost organization and installation

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-05-03 09:25:57

----- Original Message -----
From: "Noel Yap" <yap_noel_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, May 02, 2002 6:14 PM
Subject: Re: [boost] boost organization and installation

> I expect nothing more than documentation regarding
> dependencies.  Autotool checks are nice, but aren't
> really necessary if there're docs.

Two points on this, though:

1) Documenting this does add some burden to the developer (though minor), so
if it can be avoided it should be.  (I'm thinking mostly of dependencies
that occur in the implementation, not the interface... dependencies in the
interface always have to be documented.)

2) Automated tools will always be more accurate then relying on a human to
follow a specific procedure (document dependencies in this case).  The
automated tools can be used to produce the necessary documentation needed
for deployment.

> > A reorg of the code could well be something that we
> > can't do.  Depends on
> > how extensive the reorg is and whether such a reorg
> > will make development
> > efforts more difficult.  Currently the structure is
> > optimized for
> > maintainance by developers.
>
> I'm now thinking some sort of conversion script.

Possibly.  I'm thinking more of automated tools/scripts that simply pull out
the portions needed for distribution.  Don't change the structure unless
it's absolutely necessary.  I realize that this is difficult for users to do
today, but it should be possible for a group of "distribution gurus" to
create and maintain.

> > I also forsee other problems that will complicate
> > the development process.
> > If the "tarball script" has to be maintained by the
> > developers as libraries
> > change, then that's exactly the kind of impact that
> > I believe may well be
> > unacceptable.  If the changes were trivial and
> > easily done then it might not
> > be an issue, but the solutions proposed so far for
> > distribution don't fit
> > this description.  That's why I believe there has to
> > be a seperate effort by
> > other volunteers.
>
> We'll need to encode the pieces of each project
> somehow.  It'll be easier if this is already being
> done to use Jam.

Jam is only used on the libraries that need building, however.  Most of
Boost is libraries that live entirely in header files, where there's nothing
for Jam to do.

Bill Kempf