Cool C libraries we could have on hackage server
Sven.Panne at aedion.de
Sat Jun 20 06:21:50 EDT 2009
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
> 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.
More information about the Libraries