[Haskell-cafe] Re: Hidden module?

[Duncan Coutts]

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 <cristiano.paris at gmail.com> 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