[Haskell-cafe] Building Haskell stuff on Windows

[Arthur van Leeuwen]

On 7-nov-2007, at 18:38, Duncan Coutts wrote:

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

Well, honestly, that was a bit of a fib: the tarball's configure did  
in fact
not break on alex and haskell. Just the development version did.

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

Yup. No surprises there.

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

Well, I didn't have any Unix available at that point, so I kinda had to,
even though I remembered the world of pain that is autoconf and  
automake.

>> 	- 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?

It did. After an hour's worth of convincing that it really could  
work, and
remembering that autoreconf really only calls other parts of the  
autotools,
that you can also call by hand.

>> 	- ran configure for gtk2hs
>> 	- ran make
>
> Oh good, glad that bit works :-)

Yeah, if you make sure not to have any binaries in paths with embedded
spaces... ;)

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

No. It actually installed. However, building binaries against the  
installed
gtk2hs then fails with a linker error...

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

Should it? I think the big issue is autoconf rather than MSYS, and
path troubles related to make and configure... and while this is  
slightly
less painful on Unix systems it still hurts quite a bit, even there.

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

That would be nice, but having the status bits would be even better.
It makes distinguishing between 'this can be used in production code'
and 'this is for the brave, beware of lions' possible. Just having  
the dependencies
doesn't. And the distinction is a strong necessity when actually  
using Haskell...

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

Ah, yes, that is a thing. However, googling for alex does not lead me
to hackage, nor does the alex webpage. Ditto for Happy.

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

Sorry, I've been a bit unavailable due to other work-related issues.

With kind regards, Arthur.

-- 

   /\    / |       arthurvl at cs.uu.nl       | Work like you don't need  
the money
/__\  /  | A friend is someone with whom | Love like you have never  
been hurt
/    \/__ | you can dare to be yourself   | Dance like there's nobody  
watching