Pragmas for FFI imports
simonmar at microsoft.com
Wed Feb 22 05:10:52 EST 2006
On 22 February 2006 01:33, John Meacham wrote:
> On Tue, Feb 21, 2006 at 04:50:20PM -0000, Simon Marlow wrote:
>> First of all, my position on this has always been (since we argued
>> about this during the design of the FFI) that include files and
>> libraries should be kept out of the source file and specified
>> separately, since they are a part of the build infrastructure, and
>> vary across platforms.
>> I lost the argument for include files, but this is why libraries
>> cannot currently be specified inside source files. Back in the FFI
>> discussion, we didn't have Cabal, but now that we do, Cabal is the
>> natural place to specify these things.
> the problem is that package granularity is way to big for specifying
> dependencies, jhc wants all dependencies attached to each FFI import.
> the reason being that it collects only the dependencies for things
> that are actually used so for instance the following works:
> foreign import ccall "fcntl.h open" c_unix_open ...
> foreign import ccall "win32.h OpenFile" c_win_open ...
> foreign import lvm "lvmOpen" c_lvm_open ...
> openFile = case os of
> "unix" -> ... c_unix_open ...
> "lvm" -> .... c_lvm_open ...
> "win32" ->.. c_win_open ...
> and all the intermediate code remains platform independent.
You could still break this into packages - I guess I'm not convinced by
the argument that packages have too large granularity. It seems nice,
even, to put the OS-specific code into separate packages in this
More information about the Haskell-prime