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 . (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.
