FW: Library infrastructure

[Tanton Gibbs]

Don't forget three others: CPAN, CTAN, and SourceForge

Each of these is a distribution model with, I think, CPAN/CTAN being more
accessable than SourceForge because of thier categorization scheme.
Furthermore, CPAN lets you download using the CPAN.pm module which is very
nice: for example, it will download dependent modules as well as requested
ones if you don't have them.

You can further compare those schemes with something like the boost
libraries for C++.  These libraries are submitted to a rigourous inclusion
process that weeds out most of the weaker libraries (or people).  I actually
would not recommend this approach as it seems to cut down on the actual
usefulness of the library because it often requires the library to be too
general to be useful.

HTH,
Tanton
----- Original Message -----
From: "Matthew Donadio" <m.p.donadio@ieee.org>
To: "Simon Peyton-Jones" <simonpj@microsoft.com>; <haskell@haskell.org>;
<libraries@haskell.org>
Sent: Tuesday, April 22, 2003 10:24 AM
Subject: Re: FW: Library infrastructure


> I think one way to look at this is to examine similar ideas for other
> systems that work well.
>
> The FreeBSD ports tree is very successful in bringing in a diverse set
> of libraries and programs.  Dependencies and builds are pretty much
> handled automagically through some (rather complicated) Makefiles.  They
> have also provided a fairly nice web interface for browsing and
> searching the ports tree.  Contributions and updates are handled through
> CVS.  Conceivably, this could handle issues like building and installing
> libraries for each installed compiler, and eliminate the need to
> distribute binaries.
>
> I think that building and including libraries has to be standardized
> across the different compilers.  One big benefit of using unix is that
> the C suite is basically consistent across platforms.
>
> Other random thoughts...
>
> I think that in addition to the Report and Tutorial, a Best Practices
> document needs to be developed.  This would outline the preferable
> naming conventions, indentation, make targets, and also recommend the
> use of tools like Haddock of HDoc for generating consistent
> documentation.
>
> I am willing to use my DSP library as a guinea pig for any ideas (it is
> still a little immature, though), and to help out where I can.
>
> --
> Matthew Donadio (m.p.donadio@ieee.org)
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
>