If, following this thread, you conclude that GHC should do something different than what it does, can you submit a Trac ticket? With a small example? Thanks S | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of | Duncan Coutts | Sent: 06 March 2008 00:24 | To: Ross Paterson | Cc: glasgow-haskell-users@haskell.org | Subject: Re: scope of header files | | | On Wed, 2008-03-05 at 23:46 +0000, Ross Paterson wrote: | > On Wed, Mar 05, 2008 at 11:16:14PM +0000, Duncan Coutts wrote: | > > I was under the impression that with ghc, ffi import declarations like | > > this do not escape the module: | > > | > > foreign import ccall unsafe "foo.h foo" foo :: IO () | > | > GHC can inline the stub across module (and thus package) boundaries, | > so the #include can escape. | | I've been informed before that: | | foreign import ccall unsafe "foo" foo :: IO () | | can escape and needs -#include on the command line and for all client | code. However for ghc: | | foreign import ccall unsafe "foo.h foo" foo :: IO () | | does not escape because ghc does not track which .h file should be | #included later. It's not that it couldn't escape according to the FFI | spec but that ghc currently does not do cross-module inlining for such | declarations. That's what I've been told and it's the behaviour I've | observed, except for the case I noted. | | Quite a few packages rely on ghc's behaviour on this, or just rely on | the fact that in practise things do not get inlined that aggressively. | If we started looking carefully I think we'd find most hackage packages | that use FFI get this wrong. | | > > It's hard to tell what header files need to be used globally and | > > inherited by client packages and which can safely be used privately. | > | > No, it's easy: they're all potentially inherited. | | Which is really annoying :-) I'd like greater control over it, in | particular a way to limit headers to package scope so that dependent | code does not need the headers. | | Duncan | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users