[Haskell-cafe] Including a "XXX_stub.h" file from another Haskell library?

[Albert Y. C. Lai]

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.