On 07 June 2005 14:29, Duncan Coutts wrote:
On Tue, 2005-06-07 at 08:15 -0500, John Goerzen wrote:
On Tue, Jun 07, 2005 at 02:06:34PM +0100, Duncan Coutts wrote:
of this library" through Cabal.
I suspect that any C .h files you need at build time will also be needed by programs which use the library that you are building, since GHC can inline FFI calls across modules in which case the client module needs the .h files when compiling too. And so they should be installed along with your library (assuming it is a library and not a program you're building) and their location mentioned in the .cabal file.
Hmm. I have had several cases where I haven't included these .h files, and things still seem to have worked OK. I do that in MissingPy, for instance. I know that WASH has a .h file that it has not traditionally installed.
You're probably just lucky that GHC decided not to inline the FFI call. :-) (and/or the client module was not being compiled -fvia-C)
You can get the definitive answer as to whether you're on thin ice from one of the GHC devs.
Yes, you're on thin ice. You should assume that any header files required to compile the current module (via C) will be required to compile any module that depends on it. However, if you attach includes to foreign import declarations, like this: foreign import ccall "foo.h bar" bar :: ... then GHC will currently not inline bar in another module. This is a missing feature, and we might fix it at some point. If you use Cabal's "includes" directive, or GHC's -#include option, rather than naming header files in the foreign declaration, then your foreign calls can and will cross module boundaries. You could work around it by not compiling certain modules with -O, or perhaps something funky like {-# OPTIONS_GHC -funfolding-creation-threashold=0 #-} might work (please let us know if it does!). I don't think Cabal currently has support for installing .h files, I guess that's something we need to look into (Isaac?). Cheers, Simon