[Sorry for being absent from this discussion for a while. Teaching took its share...] Sven Panne <Sven_Panne@BetaResearch.de> wrote,

Simon Marlow wrote:

...

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. [...]

I'd go even one step further: Often even the names of #include files differ for the same API, or you have to #include some other headers first, etc., just take a look into GHC's RTS for example. If we specify #includes in the FFI, we effectively resort to autoconf or something like that in our hand-made #include files most of the time, I fear. (or clutter up the Haskell sources with #if #endif :-P ) But most people on this list think different and you don't have to use this feature, so I can live with that.

For .h files, you can always define your own .h file, which includes everything in a system-dependent manner. For libraries that have to be linked in, a similar mechanism is not feasible. Therefore, it is reasonable to handle `.h's and libs differently. Cheers, Manuel