
On Sun, 2009-03-01 at 13:08 -0800, John Meacham wrote:
On Fri, Feb 27, 2009 at 09:53:28PM +0100, Achim Schneider wrote:
Cristiano Paris
wrote: I had to append process and directory as dependencies but then it worked. How can I submit a patch to Hackage? Do I have to contact the owner?
In general, just try the maintainer and/or author adresses given on hsc2hs's hackage page.
I'd advice you to switch over to c2hs, which is actively developed, while hsc2hs's last update date smells like abandonware.
They serve different purposes, hsc2hs is meant to run on the actual machine the library is being _built_ _for_ to obtain information that is only available on the final build architecture/operating system. as in, an hsc file is the lowest level portable code you can write. c2hs is more of a developers tool. If anything, I think c2hs should generate hsc files, which can then be portably distributed.
Like hsc2hs, c2hs has to be run using the C headers for the target machine. It needs these to calculate struct sizes like hsc2hs does. The reason it cannot generate .hsc files and leave the rest to hsc2hs is that it also generates Haskell ffi imports. It imports the C functions at the correct Haskell types. If the C headers on a different platform are quite different then we will get a type error at compile time. With hsc2hs we'll just get a segfault. So c2hs and hsc2hs are in the same class here. They both must be run for the target machine. In theory c2hs should be a strict superset of the hsc2hs functionality. In practise I do not yet fully trust the calculation of C type sizes. It needs a comprehensive test of that first. That's why gtk2hs uses both c2hs, for function imports, and hsc2hs for C struct Storable instances. Duncan