Re: [boost] boost organization and installation

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-05-02 09:56:51

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

> --- David Abrahams <david.abrahams_at_[hidden]> wrote:
> >
> > ----- Original Message -----
> > From: "Noel Yap" <yap_noel_at_[hidden]>
> >
> At least we're on the same page on this one -- this is
> a process problem.  It's great you're working on
> solving it.

Yes, but it's not an easy problem to solve.  AFAIK, Boost is the first
project of its type.  It has specific needs and requirements that don't
exist for other projects.  As such, though we can and should pay attention
to successful processes used by other projects, none of them quite fit what
we need.  So, we're limping along a bit here as we try and define a process
that will work for us.  We'd gladly welcome help from anyone who wants to
volunteer... but before you volunteer I'd suggest learning what our specific
needs are by wading through the archives, static to noise ratio problems or
not.

> I think once the release process is improved, it will
> diminish, but not eliminate, my stability concerns --
> there's still many pieces that doesn't concern me that
> could introduce instability.

You can never eliminate them, unfortunately, because of the unique nature of
Boost.  We should be able to get things to be much better then they are now,
however.  For instance, the problems with Boost.Threads occurred solely
because it was a new library and I had few other people to rely on testing
things on other platforms for me.  A compiler farm or automated build
testing process would have helped here, and there's an effort to bring this
to reality as well, but that's a non-trivial thing to do for a project this
large that exists solely as a volunteer effort with no monetary backing at
all.

> > > In any case, all of boost is now dependent on
> > Python
> > > since at least one part of it depends on Python.
> >
> > That's just false.
>
> Why do you say that?  If Boost depends on
> Boost.Python, and Boost.Python depends on Python, then
> Boost depends on Python (ie dependency is transitive).
>  Would you agree that dependency is transitive?

There's no such library as "Boost", which may be why you don't understand
what we're saying here.  Boost is a collection of libraries, much like the
Apache/Jakarta libraries you mentioned as models for a split.  I don't think
that model will work for us, because of our unique goals and requirements,
but despite that there is no "Boost library".  If Boost.Python doesn't
build, the entire Boost build did not fail and the only library you want
have ready to roll is Boost.Python.  Boost.Threads and Boost.RegEx (the only
other libraries that are currently built, AFAIK) will function just fine
with out Boost.Python.  In fact, you can choose to build the seperate
libraries instead of trying to build the entire Boost project simply by
running Jam in the specific library's build directory.  Maybe this solution
will work better for you in the sort term?

> > > If things were distributed separately, only
> > Boost.Python
> > > would be dependent on Python.  Those that don't
> > have
> > > Python will either install Python, or not install
> > > Boost.Python.
> >
> > You don't need a separate distribution to get that.
> > The current CVS
> > state skips building the Python library if Python
> > isn't installed or
> > configured.
>
> But why download it at all?

Because management of downloads for individual libraries is something that
we can't handle... partially because there are interdependencies.

> Why complicate the entire Boost build due to a
> dependence of only one of its components?  Will this
> scale if more components have more dependencies?  Will
> it scale as well as if each library took care of their
> own dependencies?

And how would you propose they do that?  Maybe there is a solution that
would allow for this sort of distribution... but you have to keep in mind
some facts about Boost.  You can't complicate the lives of the developers to
the point that they no longer contribute because they don't have the time.
We want our libraries to be used, because this helps us evolve the libraries
over time, but that's not our end goal.  Our end goal is to extend the
language and it's libraries.

Maybe the same thing is needed here as is needed for aam.  Maybe the status
quo needs to be retained for the developers and a second volunteer effort
can work on alternative ways to distribute the libraries in a manner that
doesn't impact the developers (or the admistrators!).

> > Why don't you figure out how to do that, create
> > separate distributions,
> > and post some kind of example for us with
> > instructions for library
> > developers to keep these separate distributions in
> > good health? Then we
> > can evaluate your claim.
>
> OK.  I'll start with the Concept Checking library.

I'd encourage such an effort... but I'd caution you to pay attention to the
unique needs of Boost in this regard.  So, again, I'd suggest you wade
through the past threads on this subject.  I'll go a step further... I'm
willing to help any group of users that want to start a BoostUsers
organization to handle distribution issues.  I can help you to understand
our needs (provided you do some of the legwork yourself... my time is
limited), help to coordinate with the Boost membership, etc.  I think this
would be a nice addition to the current BoostUsers mail list, which I'm a
moderator of any way.  I think everyone could benefit from such an effort.

Bill Kempf