Re: [boost] boost organization and installation

From: Noel Yap (yap_noel_at_[hidden])
Date: 2002-05-02 18:14:35

--- "William E. Kempf" <williamkempf_at_[hidden]>
wrote:
> > I really think such requirements need to be
> > documented, especially for this project.
> 
> Granted.  Maybe you can document them as you wade
> through the archives?  We
> can update them after that.

I'll do the best I can.  I guess the prime one is:
The Boost project is primarily geared towards Boost
developers, not users, since its goal is to be adopted
by the standard, not to be used as a separate entity.

> > Yes, exactly.  I think each independent piece of
> Boost
> > should be installable separately.
> 
> That's a worthy goal, but it can't impact the Boost
> development efforts.
> That's why I'm proposing a seperate effort to
> address distribution needs.

That's a good idea.

> Theoretically this could be accomplished.  The
> problem is that the
> dependencies sometimes are either internal or
> external (i.e. they're needed
> by either the interface or the implementation) which
> can impact what's
> required for distribution.  More over, the
> dependencies can change on a whim
> (especially when they are internal dependencies). 
> Considering the goals of
> Boost I don't think we can expect any more out of
> the developers then
> documenting and/or e-mail dependency changes to
> someone.  We can't expect
> them to change any distribution procedures/scripts
> that occur because of
> these changes.  (That is, other then changing any
> Jamfiles if required by
> the library.)

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

> No, and in some cases this is a fluid thing (i.e.
> the dependencies change
> intermittently, or even frequently).

OK, we'll need to deal with this.

> The difference in view points is that as a developer
> I deal with Boost as a
> large package (though I don't care if certain parts
> fail to build... heck I
> often don't build the parts I don't care about). 
> I'm not concerned with
> (nor should I be, because my end goal isn't
> distribution/use) how to manage
> dependency information required to install portions
> of Boost.  From my
> perspective what's needed is either a seperate
> effort that deals with these
> issues with out impacting me, or an automated system
> for dealing with these
> issues that minimally impacts both my time and the
> requirements on tools
> that need be present on my system.  The Boost.Build
> system may be able to
> address some of the automated system requirements
> that distributions will
> need, but where it can't I think we'll need the
> seperate volunteer effort.

Yes, developer environments will need to take
priority.

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

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

> For the most part they evaluate a library's design,
> not it's implementation.
> The libraries have been designed in a manner that
> makes it possible for
> evaluation according to this criteria.  Having
> seperate installation
> packages for the various libraries may or may not
> help in such an
> evaluation, but the current state is good enough.

I see.

Noel

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