Cool C libraries we could have on hackage server

[Sven Panne]

Am Freitag, 5. Juni 2009 01:53:30 schrieb Maurí­cio:
> I just submitted bindings to libusb, and realized I should
> comment pkgconfig-depends in .cabal since libusb-1.0 is not
> installed on the server, or cabal would refuse building it.

That's a general problem for many bindings if you directly use plain "foreign 
import".

> There are many libraries we probably would like to have bindings
> for, but we need to have them on hackage to do that. What if we
> generate a wish list of really trusted and important libraries
> we would like to use, and then test if they build on hackage,
> and install in /usr/local those that do?

This approach simply doesn't scale, or at least involves *much* work and build 
infrastructure: Some Linux distros e.g. build packages by creating a build 
environment from scratch(!) in a chroot environment, containing only those 
dependencies which are stated by the package description, but this is not 
something we should expect from Hackage IMHO.

After my long experience with the OpenGL/GLUT/OpenAL/ALUT packages, I think 
that one should forget about plain 'foreign import' completely and lookup API 
entries dynamically at runtime, using 'foreign import "wrapper"' plus the 
usual CAF trick for memoization of the entry (see e.g. the OpenGLRaw package). 
This completely removes the necessity for any libraries or headers on the 
build machine, with the f.i.w. effectively acting like prototypes in a .h 
file. I am well aware that this introduces a few minor portability issues, but 
this is a price I'll happily pay for being dependency-free during building, 
and most issues have an easy workaround: Platforms which e.g. don't support 
dynamic linking can easily be handled in a centralized way, too, by emulating 
dlsym and friends, with no changes at all on the Haskell side. On such 
platform you have more build dependencies then, but there is no way around 
this. Luckily, all major platforms don't have these issues.

One note about changes in the C API: Even plain 'foreign import' won't help 
you when the C API changes, you'll have to revert to autoconf or an equivalent 
technology then, something most people don't like, see the last decade of 
comments in various Haskell mailing lists.

Cheers,
   S.