[Haskell-cafe] package maintainers: updating your packages to work with GHC 6.8.1

[Duncan Coutts]

On Mon, 2007-11-05 at 12:47 +0100, Henning Thielemann wrote:

> When Cabal development started I suggested to use Haskell code as
> configuration file, because there will be much extensions and the package
> description will not fit into a simple syntax soon.

So of course there is a trade-off to be made in the expressiveness of
the language used for package descriptions & build procedures. My
experience with build systems (and as a gentoo packager I've seen quite
a few) tells me that a full turing complete language gives developers
too much rope with which to hang themselves. Developers make packages
which work on their systems; they cannot be expected to test in lots of
different environments. So inevitably platform-specificisms creep in
because there is no easy way to check for their absence (you'd have to
actually go and build on a dozen different platforms). With a less
expressive language that hides platform details there is more wiggle
room for the packaging system to interpret the package in a way that
makes sense for different platforms.

The one place we do have general Haskell code in in Setup.hs files. I've
seen quite a few of these now and almost every single non-trivial
Setup.hs is wrong in some respect. They work in the normal case on the
developers machine but fail when building a distro package (where the
build and install steps are separated) or would fail on windows or a
myriad of other things. By contrast when we have some bug in Cabal on
some platform we can fix it in one place, not in the Setup.hs file of
every single package.

> This suggestion was rejected because the Package description should be
> readable by an IDE. With the flags and package version comparison we
> move quickly to a Turing complete scripting language in form of a
> package description. :-)

It's pretty important that it never gets there :-).

> Btw. does the Setup.hs script still serves a purpose?

Some, but as little as possible. I'd expect only 10% of the most complex
packages will need to use them in future.

Duncan