Re: [boost] boost organization and installation

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-05-02 14:36:29

----- Original Message -----
From: "Tanton Gibbs" <thgibbs_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, May 02, 2002 2:04 PM
Subject: Re: [boost] boost organization and installation

> William,
>
> I'm a newbie to Boost, but not to programming or C++, and I would like to
> help get the Boost distribution process on its feet.  I realize that the
> lack of developer time and support has prevented the emergence of a
> distribution system like Boost deserves, but times are changing.  More and
> more is being said about Boost in the trade journals, and more and more
> programmers are going to want to see what all the hype is about.  Having
an
> excellent distribution mechanism will keep these newly interested
developers
> from sighing and giving up when they have to figure out what header files
> depend on each other (yes, I know there is a web page, but they still have
> to go manually look at it) and it should also alleviate the burden of
having
> to copy these files to their final destination.  I'm also a big Perl fan
and
> I think CPAN is an amazing demonstration of how good a distribution system
> can get.  Naturally, I don't propose to set up CPAN for Boost.  We need to
> take baby steps toward our goal (once we determine what our goal is!).
This
> message is just saying that I understand that and am willing to help.
I'll
> start poring though the archives looking for what the maintainers need
from
> a distribution system, since I feel their plight (too few people, too much
> to do) as well as what the contributors need( gotta be easy to update! )
and
> finally what the users want ( we need to know easily what works (lotsa
> tests!), and what does work we want installed for us (with
dependencies!) ).
> Any help or direction with this task would be greatly appreciated.

Some opinions about what's needed for distribution which isn't directly
covered in the archive (what's there is what's required for developers, and
a distribution system can't interfere with those needs):

* Requirements for additional tools/technologies (such as perl) need to be
kept to a minimum, and should usually be restricted to things you can
reasonably expect the user to have.

* To meet the above requirement there may well need to be multiple
distribution mechanisms for various platforms.  For instance, on *nix
platforms AAM would work nicely, but on the Windows platform you should
instead provide MSI packages.  (Note, I'm not endorsing either technology as
the "right" solution, only pointing out that at least these solutions are
based on technologies that are almost assuredly already present on the
specific platforms).

* Breaking out Boost into multiple installation packages may be beneficial,
but you have to do so in a manner that doesn't require significant changes
to the current Boost structure or prevents the normal distribution that
developers use today.  This means there may be a need for a seperate CVS
repository for release distributions... or it may not, time will tell.

* There has to be an "owner" of any distribution mechanism... someone that
will maintain the scripts/etc. as Boost evolves.  This person(s) will have
to work with the developers, but it's important that the needs of
distribution don't stand in the way of the developers.  What this means is
that the developers should never have to touch any scripts required to
handle the distribution.

So, before any effort gets underway I'd hope that we could pinpoint at least
a few people interested in volunteering with this effort, and then to
establish an online community for designing and implementing the solution.
If I get a few dedicated volunteers I'll take on the responsibility of
setting up this community, and will help with coordinating the efforts of
both the distribution and the developer communities.  Beyond that, however,
I don't have the expertise necessary for developing a solution here, just to
be clear on what I'm volunteering to do.

Bill Kempf