Duncan Coutts wrote:
On Thu, 2007-11-08 at 22:04 +0000, Andrew Coppin wrote:
According to the instructions, if I'm understanding this correctly, you're supposed to be able to unpack a package, and do
runhaskell Setup configure runhaskell Setup make runhaskell Setup install
Yep, that's the procedure. Though as I keep telling everyone we're trying to replace that with just:
cabal install blah
I tested this on Windows the other day, it's nearly working, just a couple bugs to go.
Mmm, OK.
I tried to install HaXmL. It seemed to install, yet GHC insisted it wasn't installed.
Now that one I would expect to work under windows since it's pure Haskell code.
As far as I can tell, it seemed to *compile* OK. It just wouldn't *work* once installed. GHC insisted that no such package exists... (Registration bug?) This was a while ago I guess.
But now I'm just wondering if it hasn't been tested on Windows very much...
That's a big part of the problem. Most developers cannot or do not test under windows. This should not be a problem for pure Haskell modules but for anything that binds to C libraries it's a major problem. Under unix we can usually assume that the C library and it's header files are installed in a standard location. Under windows that's never true.
Then as you noted, some packages use configure scripts which use sh. That'll never fly on a standard windows install. Hopefully over time we can replace those scripts with some better solution using Cabal.
Can somebody explain to me, in simple words, what "Cabal" is actually supposed to do? I mean, when I write Haskell code, I just give people the source code, they compile it, it works. What is this Cabal thing supposed to be achieving?
I realise it's much easier to sit here and criticise than to actually do something about fixing the problem. Clearly Cabal must work for somebody, so I was just wondering if my Cabal problems are because I'm on Windows, that's all.
So the ones I would expect to work out of the box on Windows are the packages on hackage that use "build-type: Simple" and do not use "extensions: ForeignFunctionInterface".
Apart from that, it's going to be hit and miss until we work out a better system for reporting what works and what doesn't from hackage on different platforms.
Some packages that use FFI work fine, like Cabal itself, or the zlib, bzlib packages. But those were specifically tested on Windows.
Yeah, sounds like there just needs to be some way to annotate entries to say how testing a thing is, where it's been tested, etc. Doesn't sound too hard. [For the person who doesn't have to write it anyway... ;-) ]
(For what it's worth, I actually managed to build Gtk2hs from source under Linux - and I've never built anything on Linux before! It was really quite simple though. I mean, took about 2 hours to think about it, but it's a very old laptop...)
:-)
(btw the Gtk2Hs INSTALL file describes how to configure for a quicker build)
I didn't read any documentation. Just downloaded a tarball, spent 20 minutes reading the man page to figure out how to untar it [can you tell I'm a Unix expert?], and then run three "make" commands. The configure state complained about a whole bunch of things (e.g., GTK+ isn't installed... doh!), and then it all worked OK. It did take a vast amount of time to build though; nailed my poor little Mobile Athlon 1700 to the wall...