[Haskell-cafe] 1,000 packages, so let's build a few!

[Andrew Coppin]

In celebration of Hackage reachin over 1,000 unique packages, I decided 
that I would re-visit the problem of attempting to build them on Windows.

I began by removing all existing Haskellness from my PC. I now have a 
vanilla Windows XP (32-bit) system with Service Pack 3. So, let's see 
what we can do here...

- Install GHC 6.10.1. As you'd expect, no issues here.

- Now, let's install stream-fusion. First let me ch... woah! What the hell?

OK, it seems that Google is temporarily "broken". (All websites show up 
as "this site may damange your computer".) Obviously this has nothing to 
do with Haskell, but it makes navigating Hackage moderately more 
tedious. Oh well, anyway, where was I?

Ah yes, I already have the tarball for stream-fusion-0.1.1, but I see 
that the latest release is 0.1.2.1. (Unfortunately, there doesn't appear 
to be any way to determine what the difference is between the two 
versions...)

- Right, I've got the tarball for stream-fusion. Now let's see if it 
will install...

J:\Haskell\unpack> runhaskell Setup configure
J:\Haskell\unpack> runhaskell Setup build
J:\Haskell\unpack> runhaskell Setup install
J:\Haskell\unpack> ghc-pkg list
...stream-fusion-0.1.2.1...

OK, nothing much wrong with that then. :-D

- Hmm, doesn't GHC 6.10.1 now come with Haddock included? I wonder if 
there's a way to ask Cabal to build the docs for me...

[Grr! Google is still busted.]

Ah, yes there is. OK, let's try this:

J:\Haskell\unpack> runhaskell Setup haddock
...
Data\Stream.hs:292:33: parse error on input `!'
haddock: Failed to check module: Data.Stream

Uh... OK. So I guess I *won't* build the docs for that one then. :-/ Oh 
well, maybe it's a one-off failure? Let's try some more packages...

- Next up, let's try the excellent ansi-terminal package. Checking 
Hackage [again without Google] and I see that the tarball I've got is 
still the latest version (0.5.0). Let's see what happens now...

J:\Haskell\unpack> runhaskell Setup configure
J:\Haskell\unpack> runhaskell Setup build
J:\Haskell\unpack> runhaskell Setup haddock
J:\Haskell\unpack> runhaskell Setup install
J:\Haskell\unpack> ghc-pkg list
...ansi-terminal-0.5.0...

Well, that installed OK. And look... it's given me a little folder full 
of Haddock documentation. How nice! Pitty it's burried 5 subfolders deep 
on the system drive with no hyperrefs to it... but I guess I could just 
bookmark the root folder or something? That'll work. (I.e., when I add 
more packages, it'll still be easy to navigate to their documentation 
this way.)

- Now on to the ambiguously-named "binary" package. Again, I have a 
tarball for 0.4.2 but the latest is 0.4.4. (And, again, no indication of 
how this is different. But let's hope the difference is that it's fixed 
to work with GHC 6.10...) Configure, build, Haddock, install... no 
issues. That's refreshing.

- OK, so what have we done? We've done stream-fusion, which is 100% 
Haskell. We've done ansi-terminal, which only links to standard Win32 
headers [which, oddly, seem to come bundled with GHC]. And we've done 
binary, which (I think!) comes bundled with a few small snippets of C. 
Now let's try something harder...

- Gtk2hs doesn't seem to want to work with GHC 6.10 yet; that's a pitty. 
It's a nice library. OTOH, how many Windows users have GTK+ installed? 
It's fairly uncommon. Fortunately you can just bundle the DLLs along 
with your app; unfortunately there's *a lot* of them, and they're quite 
large. And, obviously, you get a very non-native look & feel. Still, it 
*is* a nice library, and I'm sure at some point people will hassle 
Duncan to the point where an update appears. ;-)

- A better choice, theoretically, should be wxHaskell. As I understand 
it, wxWidgets is supposed to look native. (Do you still have to bundle a 
DLL? Or is it statically linked in? Or...?) Oh well, I'd like to at 
least try it out and see how it works...

Hmm, looks like you can obtain it via Cabal, or there's a special 
Windows build where you just run a BAT file and it registers everything 
for you. Let's try that first...

"Click on the newly created wxhaskell-0.11.0\bin\wxhaskell-register.bat
program to register the wxHaskell package.

To uninstall, you can click on
wxhaskell-0.11.0\bin\wxhaskell-unregister.bat and than remove the
wxhaskell-0.11.0 directory."

That sounds easy. Let's try it...

        1 file(s) copied.
        1 file(s) copied.
        1 file(s) copied.
- register packages
'ghc-pkg' is not recognized as an internal or external command,
operable program or batch file.
'ghc-pkg' is not recognized as an internal or external command,
operable program or batch file.
error:
  Unable to register the package using "ghc-pkg".
  Maybe you have an incompatible version of ghc installed?

Press any key to continue . . .

Uh... what?

OK, let's see if I can figure out what this batch file is trying to do...

Er... wow. o_O

Alright, there's no way I'm going to figure this out. I can't even tell 
where it's trying to install to or anything.

Hmm. Well, it looks like it's all compiled and it's just trying to copy 
a few files and register them with GHC. That's probably a lot simpler 
than trying to actually compile from source using Cabal. I don't know 
what's confusing it, but maybe somebody in HCafe will know? I'm going to 
leave this one for now...

- Another exciting package is the Haskell binding for libSDL. I am just 
*dying* to start doing some sound coding with Haskell, so I'm very 
interested in getting this one to work. Last time I tried it failed 
miserably, but let's see what we get this time around...

Hmm, OK. Well let me see now... There's a project on Sourceforge called 
"hSDL" which seems to be dated Apr 2005. Then there's a thing called 
"hsSDL" on somebody's website dated around Feb 2008. And finally on 
Hackage itself there's a "SDL-0.5.4" dated Apr 2008. Oh... goodie. Well, 
let's go with the latest date, shall we?

OK, download SDL-0.5.4. Unpack. Let's see if there's any useful 
documentation in here... Ah, "Win32". What does that contain? Mmm, looks 
useful. OK, let's follow these instructions and see what I get...

Need to grab libSDL... Downloaded SDL-devel-1.2.13-mingw32.tar.gz. 
Unpacked it to C:\SDL.

OK, now what? Ooo, manually edit the Cabal file... goodie! OK, well this 
shouldn't be too hard...

Right, now... configure... That looked OK... build...

Preprocessing library SDL-0.5.4...
Graphics\UI\SDL\General.hsc:1:17: SDL.h: No such file or directory
Graphics\UI\SDL\General.hsc: In function `main':
Graphics\UI\SDL\General.hsc:57: error: `SDL_INIT_TIMER' undeclared 
(first use in
 this function)
Graphics\UI\SDL\General.hsc:57: error: (Each undeclared identifier is 
reported o
nly once
Graphics\UI\SDL\General.hsc:57: error: for each function it appears in.)
Graphics\UI\SDL\General.hsc:58: error: `SDL_INIT_AUDIO' undeclared 
(first use in
 this function)
Graphics\UI\SDL\General.hsc:59: error: `SDL_INIT_VIDEO' undeclared 
(first use in
 this function)
Graphics\UI\SDL\General.hsc:60: error: `SDL_INIT_CDROM' undeclared 
(first use in
...etc...

OK, that's fantastic. Now what?

So where *is* SDL.H then? Ah, it's in C:\SDL\include\SDL. Maybe if I 
adjust the Cabal path... configure... build... OMG! It looks like that 
might even have worked... Haddock... install... Well, well! That seems 
to have worked!

Right, are there any example programs with this puppy?... No, there 
aren't. Apparently. Well that keeps things interesting...

OK, well it looks like Graphcs.UI.SDL.CPUInfo is trivial, so let's see 
if I can compile a short program that calls it. Right, well it compiles. 
Does it run?

...no. It can't find SDL.dll. Presumably if I insert that into my search 
path somewhere... woo! It works! :-D

Right, well. I guess if I can find some nontrivial examples from 
somewhere, I can try this thing out properly. (Looking at the API 
documentation, it's not very obvious how to do anything with it...)

- OK, well I guess this message is long enough already. I notice there's 
a brand new version of HDBC out, so tomorrow I'm going to attempt to 
finally make a Haskell program actually talk to a database. ;-)

TO BE CONTINUED...