[Haskell-cafe] Building Haskell stuff on Windows

[Duncan Coutts]

On Wed, 2007-11-07 at 17:34 +0100, Arthur van Leeuwen wrote:
> Hello all,
> 
> maybe I'm just not used enough to Windows, but let me explain my woes of
> today. It seems to me to be *much* too hard to get a full install of  
> GHC + GTK2Hs
> going on Windows, going from the idea that I want the currently  
> released stable versions of everything.

It is far too hard. For one thing the released tarball does not build
with ghc-6.8.1. That's why I'm working on a new point release.

> So, this is the way I progressed (from a clean Windows install):
> 	- Installed MinGW 5.1.3
> 	- Installed MSYS 1.0.10
> 	- Installed GHC 6.8.1
> 	- edit /etc/fstab in MSYS to correctly bind MinGW
> 	- Installed gtk-dev-2.10.11-win32-1
> 	- Downloaded gtk2hs-0.9.12.tar.gz
> 	- cd /d/haskell/gtk2hs-0.9.12
> 	- ran configure
> 	- discovered I needed happy (this was not documented!)

Hmm, that's not right. The gtk2hs tarballs come with the lexer and
parser pre generated. The configure script checks for alex and happy but
does not (should not) fail if they're not present and the pre-generated
code is present. I certainly build on a windows server where alex and
happy are not installed.

> 	- Downloaded happy-1.17.tar.gz
> 	- unpacked, configured, built, installed
> 	- ran configure for gtk2hs
> 	- discovered I needed alex (this was not documented!)
> 	- Downloaded alex-2.10.tar.gz
> 	- Setup.lhs of alex-2.10 did not compile due importing  
> Distribution.Simple(compilerPath)
> 	- Installed darcs
> 	- darcs got alex development tree
> 	- Setup.lhs of alex-2.10 compiled
> 	- building alex-2.10 failed due to wishing an existing alex
> 	- broke down and downloaded alex-2.10 binaries
> 	- installed alex-2.10 next to happy in C:\Program Files\Haskell\bin
> 	- ran configure for gtk2hs
> 	- ran make
> 	- discovered alex should not be in C:\Program Files as make breaks  
> on paths with embedded spaces...
> 	- copied C:\Program Files\Haskell to C:\Haskell and modified $PATH
> 	- reran configure for gtk2hs
> 	- ran make
> 	- discovered gtk2hs 0.9.12 hides 'containers'

That's the bit where we notice gtk2hs-0.9.12 was released well before
ghc-6.8.1 and thus does not work with it. Every non-trivial package
needs updating in various minor ways to work with ghc-6.8.1.

> 	- broke down and darcs got gtk2hs development tree
> 	- installed automake
> 	- ran autoreconf

I've never managed to get automake to work on windows. I always generate
tarballs under linux and then build them on windows. This also allows me
to avoid installing happy/alex on windows.

> 	- discovered automake for MSYS 1.0.10 is too old
> 	- installed automake-1.9
> 	- ran aclocal-1.9
> 	- ran autoconf
> 	- ran configure
> 	- discovered I need to explicitly add GTK libs to aclocal
> 	- ran aclocal-1.9 -I with GTK library path
> 	- ran autoconf

Wow, it actually worked did it?

> 	- ran configure for gtk2hs
> 	- ran make

Oh good, glad that bit works :-)

> 	- complained on IRC
> 	- ran make install

I expect it fails in the package registration stage right? Yes, I never
do that, I always build images for the installer and never install
direct, so that path is probably bit-rotted.

> 	- sighed deeply
> 
> Ofcourse, on complaining I learned that hackage contains alex 2.2,  
> rather than 2.10, but that is not apparent from the alex webpages. It
> seems to me that much of this is way too hard to figure out...
> figuring out the dependency graph should not be necessary, as the
> developers should know what parts go into their code!

Yes it is too hard. In the case of Gtk2Hs I think it'll be easier when
Gtk2hs changes to use Cabal for it's build system. Then it will not
require mingw/msys which should improve things dramatically.

> Furthermore, as much as I applaud hackage, it is not ready for use,  
> as it does not afford things you might want, such as searching for
> latest (stable) releases of packages.

Yes, there is nothing to distinguish "latest" from "stable". With
sufficiently accurate deps I think this is solvable, and perhaps the
ability to tweak the deps after a package is released (to tighten them
if they were too lax for example).

> Plus, it is still not the default go-to place for many things.

That's changing reasonably quickly. Especially if you put pressure on
maintainers of packages that you get from anywhere other than hackage.
Repeat the mantra "if it's not on hackage it doesn't exist".

> Maybe developers that decide to put their most recent versions on
> hackage could document that on the main webpages of their code? (I've
> ran into this with FileManip as well, not just with Alex).

Good idea.

So the good news for you is that the windows installer for Gtk2Hs (which
will be compatible with ghc-6.6.1 and 6.8.1) will be released in a day
or so. I might ask you to try a pre-release for me.

Duncan