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.