Developing cabal2wix - building Windows installers automatically
duncan.coutts at worc.ox.ac.uk
Mon Aug 6 09:26:43 EDT 2007
On Mon, 2007-08-06 at 01:05 +0300, Esa Ilari Vuokko wrote:
> 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
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
> 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.
> 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.
More information about the cabal-devel