On Mon, 2008-06-23 at 17:15 +1000, Manuel M T Chakravarty wrote:
John Lato,
I have a package (binding to a C library) that uses C2HS that I'm cleaning up for a hackage release. I was wondering if there are any guidelines as to which files to include and how to set up the build. I could include the .chs file, but then anyone trying to build the library would need C2HS. Alternatively, I could include just the .hs file I get from running C2HS (and C2HS.hs), which would be okay, but I would like to provide all available source files for anyone who's interested. Including both seems like asking for trouble in the build process. Does anyone have any recommendations for this? I couldn't find anything addressing it in the cabal packaging guidelines.
Unfortunately, the inclusion of only the .hs file is in general not sufficient. C->Haskell hardcodes OS and C compiler-specific information in the .hs file, and hence, it is not portable.
Right, and Cabal knows this so will not put the result of c2hs into the tarballs (where as it will for alex/happy). So, yes, just list all the modules in the .cabal file in exposed-modules or other-modules as appropriate and use cabal sdist to make the tarball. If you have dependencies between your .chs modules (ie if you use {# import #} hooks) then you will need to list the modules in the right order in the .cabal file because Cabal does not yet have support for working out the dependencies itself and doing them in the right order (we're working on it for a GSoC project this summer though). Another thing you should also use in the .cabal file is: build-tools: c2hs Duncan