On Mon, 2007-08-06 at 01:05 +0300, Esa Ilari Vuokko wrote:
Hi,
I decided to try to build a cabal -> wix converter, cabal2wix, to make it easier to generate Windows installers for cabal-packages. My main target is ghc-compiled libraries. There are few issues I've ran into and I'd appreciate any comments on them.
I'll try to publish the darcs repo somewhere if there's interest.
Some of the issues are gray, as I don't understand all the details myself, and reading Cabal's code isn't very enlightening.
Issue 1: Cabal puts (at least) docs under Program Files\Common Files - this separates docs from other parts of the program by logical placing, which is pretty annoying if you need to offer way to relocate installation (say to user's home directory). I am considering moving docs next to library files in installers cabal2wix generates.
Issue 2: setup copy --destdir=foo is confusing in Windows. If my prefix is c:\Program Files (like it is if I run configure without options), the directory structure after copy is foo\Program Files - ie. unsuable locally because drive letter is missing,
It's not clear that's true, if you copy the files in foo\Program Files\ to C:\Program Files\ and register the package with ghc-pkg then it should work fine.
and unusable at remote locations, because Program Files is not localized. I'd like not to use all possible directory flags at configure time, because it is impossible to know how different packages react to them.
I'm not sure why you say that; what they mean does not vary between packages. I think setting the prefix and other directory flags should be fine. Since you want a relocatable package you do want to set prefix as ".". As you said, some of the other bits are not relative to prefix on windows, like the docs. So that's a problem.
(currently cabal2wix assumes no directories were changed.)
Suggestion: Make copy-hook unable to copy random files on their own, this way there could be setup copy --list-links, which would be nicer, IMHO. As the list could also differentiate between different types of files. Profiling lib, shared libs (dev and end-user installer in one.)
I don't think it's a problem that cabal doesn't support this since it's easy to generate an install image by copying into a temp dir. This is the way most other build systems work (both unix and windows ones). All you'd be saving is one bunch of file copies which is really pretty cheap.
Issue 3: Currently cabal2wix reads dist\setup-config to find out package and compiler information. This is pretty stupid, as LocalBuildInfo structure might not be that stable, and cabal2wix can only guarantee working with the same Cabal it was built with. cabal2wix could read installed-pkg-config (and maybe .cabal) to get package name and version. But I can't see how to get compiler information from any other place than setup-config.
You an do that by calling functions in the Simple build system.
It'd also make sense to read solved build-depends info, but I currently don't have plans to do that.
Similarly.
Big thank you for Duncan and Ian for useful comments at irc. Issue list is shorter now ;-)
Good :-) This is potentially a very useful project. We do have lots of windows users and we don't yet have things as easy for them as we should. In the long term we would want to tie this into the hackage build server to build binary packages and the cabal-install tool to download and install them. Duncan