Re: [boost] boost organization and installation

From: Noel Yap (yap_noel_at_[hidden])
Date: 2002-05-02 15:37:38

--- "William E. Kempf" <williamkempf_at_[hidden]>
wrote:
> > 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 really think such requirements need to be
documented, especially for this project.

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

This is my point.  I downloaded 1.27.0 which had a
broken Threads component.  As a CM I cannot bless this
release for our use even though the other portion that
we actually do use may be fine.  If I could get a
minimal package that I can install, I wouldn't have a
concern whether another portion of Boost built or not.

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

Yes, exactly.  I think each independent piece of Boost
should be installable separately.

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

Of course, I can't comment on this since I know
nothing of the requirements, but right now, I don't
see why it can't be treated completely as separate
components (it seems that it's already treated like
this partially), in which there are core components
(ie config) and the other components which may depend
on some other components.  Each component can be
tarballed into their own dist package allowing
separate installations.  One giant tarball can also be
created for those not interested in small granularity.

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

As a developer, I completely understand this.  This
won't hold water for a configuration manager, though. 
Well, technically, assuming Boost.Python didn't build
'cos python isn't installed, then my statement isn't
true since, technically, there were no real errors in
the build.  However, if Boost.Python didn't build due
to, say, a syntax error in the code, then a
configuration manager cannot bless _any_ of this
particular Boost release (ie 1.27.0).  A configuration
manager cannot also pick and choose pieces of
different Boost releases (unless s/he is completely
sure of the interdependencies).  The ideal situation
for a CM, as I've said, is to be able to obtain one
package per Boost component that can be built, tested,
and installed separately.

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

Yes, this will cover half the problem.  The other half
is installation.  I think the installation of the
actual libraries is simple, it's the header files I'm
more concerned about.  All the header files are
packaged in one directory.  Aside from
http://www.boost.org/libs/hdr_depend.html, is there
documentation on which header files belong to which
projects?

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

I see.  I think we differ on this issue.  I think it
is the developer's responsibility to document
dependencies and the user's responsibility to install
any dependencies (JDE is distributed this way).  Any
circular dependencies should be contained within the
same package, but from what I see, there are no
circular dependencies among Boost components.

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

IMHO, it shouldn't complicate anything at all and
might even simplify things.  All that's really needed
(although new namespaces would be nice), is some a
tarball script that would package up the source and
documentation.  I think the only real change might be
a reorg of the code (although I would imagine that
each project might already have separate source trees
for their stuff).

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

Ahhh.  This is the heart of the matter.  I've been
working under the assumption that usage was the end
goal.

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

I think this is a prereq to any aam development since,
if this were done, a steady transition path can be
established.  If it's not done, it's an all or nothing
proposition.

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

This would be great.  But, yes, I really do need to
understand the requirements more.  The fact that the
end goal is to put something in the standard makes me
want to reevaluate both the need and the want to
separate out the packages.

My first thought on this is that separation would make
it easier for the standards body to evaluate each
package separately.

I'll start digging through the arhives ASAP (although,
like you, I'm busy with other stuff as well).

Thanks,
Noel

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com