Duncan Coutts:

On Thu, 2006-07-06 at 10:30 +0100, Duncan Coutts wrote:

...

On Wed, 2006-07-05 at 20:58 -0700, Anatoly Yakovenko wrote:

...

On 7/4/06, Arjan Oosting wrote:

...

Op di, 04-07-2006 te 09:09 -0700, schreef Anatoly Yakovenko:

...

I can't get c2hs to build on windows with ghc-6.4.2

I get a little farther, but it still doesn't work:

Actually, c2hs's setup is doing something that only works on unix. In fact it doesn't even always work on unix. For the Gentoo ebuild we changed it because it doesn't work in the context of installing into a temp dir.

A temporary hack is to change the Setup.hs to be just:

import Distribution.Simple main = defaultMain

it means that c2hs's --copy-library feature will not work but everything else should. We'll have to look into doing that in a more portable way.

With the latest Cabal (as included in recent GHC), the postInst.sh (which is the problem) can be rewritten in Haskell and added to Setup.hs directly. That should remove this particular problem (but will of course mean that c2hs doesn't work anymore with earlier versions of Cabal, but that is probably secondary).

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. Manuel

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