Duncan wrote,
Actually it turns out the c2hs is doing a lot of things that are not portable to windows. It'll need some effort to fix. Any helpers?
What else apart from pathname separators? It'd be great if somebody could look into that.
The use of configure(.in) is the main problem. Most Windows users do not have mingw/cygwin.
I've been looking through what c2hs uses configure for and what portable replacements there are:
* for finding the os and arch in c2hs/toplevel/C2HSConfig.hs.in for the platform spec system. Perhaps this could be replaced with System.Info.{os,arch} ?
If it is sufficiently accurate. The handling of bitfields (paddings) etc depends on the os/arch and we need to know which conventions to use. Another problem is that the current approach allows cross-compilation (in configure you can specify an os/arch, rather than query). We need to support cross-compilation somehow (eg, Tony Sloane needed it for generating bindings for the PalmPilot).
* finding the temp dir. this is not actually used anywhere.
Yes, that may be obsolete now.
* substituting the c2hs version into the Version.hs module. This can be replaced with Cabal's new Path_c2hs.hs feature.
My plan was to use VersionTool for c2hs anyway. That does the version thing and integrates nicely with darcs: http://www.cse.unsw.edu.au/~chak/haskell/VersionTool/
The postinst.sh could be eliminated entirely. All it's used for is finding the location where a data file was installed. This can now be found using Cabal's new Path_c2hs.hs feature. Cabal generates that module which provides a portable way of finding the location of data files. Also the field 'Data-Files:' can be added to the c2hs.cabal file to specify extra data files that need to be installed.
postInst.sh was only meant as a stop gap measure with older Cabal. It should definitely go.
So I think the only things left are finding the copyright notice and a couple other items that are kept centrally in the c2hs.cabal file. For the moment they could perhaps just be duplicated. I've got a suggestion for how to deal with that case better in future which I posted to the cabal-devel list: http://www.haskell.org//pipermail/cabal-devel/2006-July/000027.html
Ah! Interesting. Issac was wondering whether VersionTool should be integrated with Cabal. That's kind of what you propose. It would certainly be nice to have it integrated (esp, as Cabal parses the Cabal file anyways, as you note). I am not so sure about the darcs features of VersionTool (as in, not sure how people would feel about having them in Cabal), but maybe they can be optional in some way (eg, something that may be activated via some specification in Setup.hs). Manuel