[Haskell-cafe] ANN: wavconvert 0.1.1

[Don Stewart]

duncan.coutts:
> On Mon, 2008-08-18 at 18:22 -0700, Don Stewart wrote:
> 
> > Tim wins the prize for the 500th Haskell package in Arch Linux,
> > 
> >     http://aur.archlinux.org/packages.php?ID=19205
> 
> Which, I should like to note, demonstrates why the original Cabal
> design[1] was basically right[2] in that it allows this kind of
> automated translation into native packages.
> 
> You cannot do that with autoconf.
> 
> The other distros are following a similar course though not yet quite as
> successfully as Don has demonstrated for Arch. There are similar
> translation tools for Gentoo, Debian and RPM-based distros with varying
> levels of sophistication and automation. I think the folks who hack on
> these translation tools should get together and share code and
> experience so we can all achieve better levels of automation. The
> highest levels of automation will also require more centralised QA on
> hackage. That's where we should be going.
> 
> Duncan
> 
> [1] http://haskell.org/cabal/proposal/index.html
> [2] I'm not at all claiming credit for that design. That was decided
> well before I started hacking on Cabal.
> 

Yes, I want to write something about this soon, but essentially, having
a pure, declarative specifcation language for build dependencies -- with
no runtime initialisation (yes, I'm looking at you, autoconf!) to define
how the package is constructed -- enables analysis and translation tools
like cabal2arch, which are an order of magnitude more productive.

Use build-type: Simple!

One person can maintain 500 packages with minimal manual intervention,
while our competitors (6 erlang packages, 21 ocaml packages, 494 python
packages :) have to waste a lot more manpower keeping things in shape.

Cabal is going to benefit Haskell a lot in the long term -- this kind of
productivity improvement is game changing.


This leads nicely into the question of where we go from here. We
have central hosting, a declarative build system of the first order, and
native packages that are easy to construct. 

The next phase is a standard, comprehensive platform of packages, we can
rely on, built upon the automation Cabal enables. See the Batteries
Included proposal[1] for more info.

-- Don

[1] http://www.cse.unsw.edu.au/~dons/papers/CPJS08.html