Simon PJ writes:

...

I thought we agreed to remove the specification of libraries from the FFI, and leave it to some compiler-dependent mechanism. As Sven points out, there are going to be times when you really don't want a library at all, or in any case not one with the same name as the header file, and there will be cases where you want several libraries in some system-dependent order that shouldn't be placed in the source code.

I'm certain that at least one person (me) disagreed with removing any library specs from the FFI. I tend to the view that if the compiler needs to know about something (and can't work it out for itself) the information should be in the source code. Putting it in a Makefile or some other auxiliary structure (package configuration?) is not really clean enough for me. I don't want to have to write three different Makefiles, one for each possible compiler I could use. Please let's aim for portability.

Having said that, it is true that the FFI may not be the best place for a specification of link libraries or whatever. Maybe we should agree on some pragmas for this sort of information? In any case, I'd like to have a compiler-independent standard, whether or not it is part of the FFI.

The reason for not putting them in the source is because the names of libraries change from system to system but their APIs don't. It's possible to write a portable binding to an API if you don't have to include the libraries, but including the library names requires information from the system, which is normally picked up by a configure script. For example, what should I link to in order to get GLib? On the RedHat system here, it's -lglib, but on my FreeBSD box at home it's -lglib12, but the code for the binding remains the same. So to keep the Haskell code portable, it should omit the library names. I see the information in a package config as "meta-information" about the Haskell code: information about the particular environment in which the code is running. It's certainly not a perfect separation, because some system-specific things have to be compiled into the code to get decent performance (the values of the errno constants, for example), but at least it leaves the Haskell code independent of filenames and directory locations. If you want to put this information in a pragma for NHC that's fine. I'd much prefer to see NHC use our package scheme though: I'll be happy to incorporate any changes needed by NHC into the tools. Cheers, Simon