distributing packages that use C2HS

[John Lato-2]

Hello,

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.

Thanks,
John Lato
_______________________________________________
C2hs mailing list
C2hs@...
http://www.haskell.org/mailman/listinfo/c2hs

[Manuel M T Chakravarty]

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.

Manuel

_______________________________________________
C2hs mailing list
C2hs@...
http://www.haskell.org/mailman/listinfo/c2hs

[Duncan Coutts]

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

_______________________________________________
C2hs mailing list
C2hs@...
http://www.haskell.org/mailman/listinfo/c2hs

[Duncan Coutts]

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

_______________________________________________
C2hs mailing list
C2hs@...
http://www.haskell.org/mailman/listinfo/c2hs

[John Lato-2]

On Mon, Jun 23, 2008 at 5:09 PM, Duncan Coutts
<duncan.coutts@...> wrote:

>
> On Mon, 2008-06-23 at 12:51 -0500, John Lato wrote:
>
> 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.

Well, thanks for pointing this out.  I'd forgotten that the offsets
will change with platforms, even though one of the reasons I was
attracted to c2hs was because I didn't want to have to worry about
that myself.  Looks like I put that concern a little too far outside
my thoughts!  The API is definitely not the same on every platform.
There can even be size variances on the same platform depending on the
C library's build options, which is yet another item that needs to be
done on the end-users machine.

John
_______________________________________________
C2hs mailing list
C2hs@...
http://www.haskell.org/mailman/listinfo/c2hs