On Mon, 2006-04-24 at 14:44 +0100, Simon Marlow wrote:
How about just adding a couple of new pragmas:
{-# INCLUDE_PRIVATE "foo/bar.h" #-} {-# INCLUDE_PACKAGE "foo/bar.h" #-}
Sounds reasonable. This is much like my original random syntax but as a pragma.
both pragmas apply to all the foreign imports in the current module, just like the existing INCLUDE pragma. Additionally, INCLUDE_PRIVATE prevents any foreign import from being inlined outside the current module, and INCLUDE_PACKAGE does the same but for the package (this requires a little more support from GHC).
So the existing INCLUDE pagama is really INCLUDE_GLOBAL.
We can then describe more accurately what is means to give an include file on a particular foreign import: it means the same as INCLUDE_PRIVATE, but for this foreign import only.
Yes. That's what GHC currently does and the FFI spec leaves it unspecified.
The problem you mentioned, namely that people use a private header file but don't export it with the package, only happens when they explicitly use {-# INCLUDE #-} or -#include flags, right?
Yes I think so. This normally happens because users specify the header in the .cabal file and Cabal uses -#include.
In that case, we can have Cabal check that all {-# INCLUDE #-} files are properly exported with the package, and discourage the use of explicit -#include options. Is that enough?
Yes, I think that would be a great improvement and would catch most of the bugs. I was hoping we could go one step further and have ghc check that all the headers needed to compile a module are present (usually as a result of importing a module that uses INCLUDE_GLOBAL). I think it'd just be one extra bit of info for each .hi file. So yes, I'd be satisfied with a GHC-only solution but I brought it up here just in case anyone else thinks that this issue of header scope might be worth specifying more clearly in the Haskell' FFI. Specifically if it'd make sense to standardise GHC & JHC's INCLUDE_* pragma(s) into proper FFI syntax (especially since most people seem to use that rather than the official syntax). Duncan