Haskell library infrastructure coordinator

[Isaac Jones]

Hi, Peter,

Peter Simons <simons@cryp.to> writes:

> Isaac Jones writes:
> 
>  > Yes, the packages will be left to the distributors. However, I
>  > think that the library infrastructure should be able to provide
>  > some metadata and tools for assisting packagers [1].
> 
> I just realize we really _are_ approaching the problem from different
> ends! :-)

Indeed!  I've been thinking this all along :-)

> I doubt there is such a thing as a common build infrastructure on
> which everybody could agree. Just look at the reality today: We have
> BSD Make, GNU Make, Jam, Boost.Jam, Odin, Cook, Automake and only
> god knows what else -- all being actively used for all kinds of
> projects.  Even within the Haskell community, not everybody is using
> the fptools, even though it clearly can build pretty much
> everything.

This is the beauty of a layered tools approach like the one I
describe.  The "build" infrastructure can be any that the library
author likes.  We'll provide a nice default one, but the layer on top
of that structure, like Debian and Distutils, will provide a standard
interface.

> > [...] I'm rather convinced that duplicating any one system will
> > leave us with 1) the flaws of that system and 2) the flaws that
> > Haskell adds to the system by not being a perfect fit.

> Uh, I was referring to Boost's model of running the source
> repository and their success with it -- not to their build
> infrastructure.

There are several systems which run source repositories that we can
learn from, including Debian, FreeBSD, CPAN, Boost, etc.

You've done a good job convincing me that there's a lot of work to be
done in both on the distribution end and on the "building" end.  If we
work closely together, we can probably meet in the middle with a
successful system.  Do you mind helping to convert the build system
for the libraries you put together once the "building" side is ready?

Some points:

We need to isolate overlap between distribution and "distutils" (from
now on, when I say Library Infrastructure, I mean "make system" +
"distutils" + "distribution"[1]).

  - Meta information that the libraries should provide (you probably
  don't have to or want to worry about this yet) will be important to
  methods of download / depends / install

  - If not a standard make system, at least a standard method for
  invoking the make system ala distutils and Debian.  You probably
  don't want to worry about this yet either, but keep it in mind.

Here are some suggestions on how you might proceed usefully and give
us some time to come up with a plan for a build system

  - collect the libraries that are already included with various
  compilers and see what the differences are both in what libraries
  are included and behaviors of the libraries

  - find orphaned libraries (ala Numeric Quest) and try to find the
  authors to give them licenses.

  - some documentation for standards lightly based on the libraries
  currently included w/ compilers. These will probably want to include
  some reference to various licenses.  Part of this task will be to
  help new library authors realize that they should include _some_
  license with their stuff, and help them decide what license best
  fulfills their goals (my personal preference is GPL for
  applications, LGPL for libraries, and I have no trouble w/
  BSD-style.)  Does anyone know of a good, unbiased reference re:
  licenses?

  - a list of libraries that need better documentation, (which I'll be
  glad to help write)

  - develop the requirements / use cases or whatever for a
  distribution system that you plan to fulfill ala Boost.



peace,

isaac

[1]
Things that need names:

Library Infrastructure includes:
* Building (like the fptools make system, maybe we could call it
  fpmake or fpmakefiles)
* Intermediate Layer (like Distutils, we'll hold off on naming it
  until it has more form)
* Distribution (like "the hump" (OCaml) or CPAN (perl))
* A standard subset of all the libraries in the distribution, like
  whats currently included w/ the compilers (hslibs is taken, right?)

Also, I have an idea for a mascot (see section 3.5: Mascot):
http://www.haskell.org/hawiki/LibraryInfrastructure
:)