On Mon, 2008-06-23 at 12:51 -0500, John Lato wrote:
Okay, thanks. I'll just need to live with the dependency on c2hs for end-users. I suppose if that's a problem, I should have chosen something other than c2hs as a build tool.
In general though it does need to be done on the end users machine so it's not just a c2hs limitation. You may be lucky and know for certain that for the particular C API that you are binding that it is the same on every platform and contains no sizes or offsets of types (since sizes and offsets change between platforms, especially between 32 and 64bit ones). In that happy circumstance then it would be safe to bundle pre-generated .hs files. Cabal will not help you there however since it takes the conservative position that the result of c2hs (and hsc2hs and other FFI pre-processors) is platform dependent. One way to check if its portable is to look at the .hs files generated by c2hs and see if there are any numbers generated. If so then it is platform dependent. Another way of saying it is that call and fun hooks are ok but sizeof, get and set hooks are not. However even if there are no numbers in the generated .hs that doesn't guarantee you're safe. If you're binding to a .h file that might be different on different systems then you've got problems. It is quite common for lots of system headers to use slightly different types on different systems. If you're binding to a C library that has the same implementation on each system or is otherwise guaranteed to have the same C interface then you'd be ok. If you were *absolutely* sure then you could manually include the generated .hs files in dist/build/ in the same path in the tarball and it would work without c2hs installed (assuming you also removed the c2hs build-tool dep). For example see the tarball for happy and where the pre-generated .hs file lives in the tarball (of course for happy, cabal does this automatically because it knows the output of happy is platform independent). Duncan