On 2016-02-08 08:34 AM, Alp Mestanogullari wrote:

Let's say I have two Haskell libraries, `A` and `B`.

`A` uses the FFI, `foreign export` to be precise, to make a Haskell function available to C land. This generates a "stub" C header file with a corresponding C function declaration.

`B` has some C code in it and needs to include the stub header that was generated when compiling `A`, in order to call the function that I 'foreign export'ed in A.

When I "naively" include the stub header file for the module in A that contains the 'foreign export' statement, inside one of the C files of the `B` library, the said header can't be found.

A_stub.h has the problem of #include'ing <HsFFI.h>. (Read A_stub.h to see.) HsFFI.h has the problem of strongly inflicting "you have to install a Haskell compiler" on C programmers who just want to build B (which is just C code that just calls a binary library callable from C). Firstly it only comes with a Haskell compiler. Secondly its location is usually under the Haskell compiler's directory, not the usual ones configured to the C compiler, therefore either (recommended) you call "ghc -c B.c" so that it calls gcc with HsFFI.h's location, or (unmaintainable) you enter it manually. My recommendation is to ignore A_stub.h and write your own simple independent A.h. It can be correct because Haskell 2010 asserts that, for example, HsInt64 must be "signed integral type, 64 bit; int64_t if available". There is no choice. You don't need HsFFI.h to tell you what HsInt64 is, you can already enter "int64_t" today. HsPtr is even better, it is "(void *)". There is no choice. (See Haskell 2010 Report, section 8.7.) As for HsInt, yes that varies across Haskell compilers, but you are supposed to use HsInt8 or HsInt16 or HsInt32 or HsInt64.