Building Haskell stuff on Windows
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. 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!) - 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' - broke down and darcs got gtk2hs development tree - installed automake - ran autoreconf - 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 - ran configure for gtk2hs - ran make - complained on IRC - ran make install - 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! 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. Plus, it is still not the default go-to place for many things. 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). With kind regards, Arthur. -- /\ / | arthurvl@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
Hi Arthur, The correct steps to take are: 1) install GHC from the windows installer - trivial 2) install Gtk2hs from the windows installer Unfortunately Gtk2hs hasn't been updated to work with GHC 6.8.1, so step 2 will fail. The person who is going to do this is Duncan. He usually breaks down and does this once people start complaining on the mailing list.
- Installed MinGW 5.1.3
Generally, if you have to install MinGW you can pretty much guarantee that something somewhere is going to go wrong - not enough people test this route to make it reliable. Windows and Haskell is not a well travelled route, but if you stray of the cuddly installer packages, it gets even worse. Thanks Neil
On 7-nov-2007, at 17:43, Neil Mitchell wrote:
Hi Arthur,
The correct steps to take are:
1) install GHC from the windows installer - trivial 2) install Gtk2hs from the windows installer
Unfortunately Gtk2hs hasn't been updated to work with GHC 6.8.1, so step 2 will fail. The person who is going to do this is Duncan. He usually breaks down and does this once people start complaining on the mailing list.
- Installed MinGW 5.1.3
Generally, if you have to install MinGW you can pretty much guarantee that something somewhere is going to go wrong - not enough people test this route to make it reliable.
Actually, the MinGW/MSYS thing was also necessary for another package that I needed, plus, the GTK2Hs build instructions explicitly state that you need it. Oh, and I *definitely* liked the vim and bash that I got from it. No cmd.exe and it's odd syntax for me! :)
Windows and Haskell is not a well travelled route, but if you stray of the cuddly installer packages, it gets even worse.
But it shouldn't. Really it shouldn't. Even though Windows is not my preferred platform, it is by no means different enough to warrant such additional complexity. Plus, GHC is developed at Microsoft, and the currently most featureful Haskell IDE is on Windows... With kind regards, Arthur. (Who will surely do more Windows development with Haskell soonish) -- /\ / | arthurvl@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
On Wed, 2007-11-07 at 23:20 +0100, Arthur van Leeuwen wrote:
With kind regards, Arthur. (Who will surely do more Windows development with Haskell soonish)
Good! We need more developers to help us with windows stuff. We're in this difficult situation where half of our users use Windows (according to the GHC survey) but the vast majority of developers use Linux, several use Mac OS and approximately 3 use Windows as their primary platform. So supporting Windows becomes difficult. Duncan
| > Windows and Haskell is not a well travelled route, but if you stray of | > the cuddly installer packages, it gets even worse. | | But it shouldn't. Really it shouldn't. Even though Windows is not my | preferred platform, it is by no means different enough to warrant such | additional complexity. Plus, GHC is developed at Microsoft, and the | currently most featureful Haskell IDE is on Windows... We build GHC on Windows every day. I use MSYS with no trouble. But the path *is* less travelled, and that means that fewer people know answers, and more problems are not ironed out by previous travellers. There are also significant gotchas, mostly to do with the attempt to make Windows look like Unix, that are hard to grok. For example, shell quoting conventions, and MSYS's pathname mangling that makes MSYS look more like Unix. GHC's build system just works around these. Still, the more people travel the path, the smoother it'll get. Please help us make it better. Simon
Simon Peyton-Jones wrote:
| > Windows and Haskell is not a well travelled route, but if you stray of | > the cuddly installer packages, it gets even worse. | | But it shouldn't. Really it shouldn't. Even though Windows is not my | preferred platform, it is by no means different enough to warrant such | additional complexity. Plus, GHC is developed at Microsoft, and the | currently most featureful Haskell IDE is on Windows...
We build GHC on Windows every day. I use MSYS with no trouble.
Are there any reasons to use mingw+msys instead of mingw+cygwin? Last time I needed a quick build of gtk2hs (summer of this year?), I run in so many problems with msys (too old versions of tools in it) that I rather patched gtk2hs build system to make it work with cygwin. Well this may not be an issue any more since I see a newer version of msys is available from September. Peter.
Peter Hercek wrote:
Simon Peyton-Jones wrote:
| > Windows and Haskell is not a well travelled route, but if you stray of | > the cuddly installer packages, it gets even worse. | | But it shouldn't. Really it shouldn't. Even though Windows is not my | preferred platform, it is by no means different enough to warrant such | additional complexity. Plus, GHC is developed at Microsoft, and the | currently most featureful Haskell IDE is on Windows...
We build GHC on Windows every day. I use MSYS with no trouble.
Are there any reasons to use mingw+msys instead of mingw+cygwin?
The GHC build system supports both. The Cygwin route is usually more likely to work, because that's what the nightly builds use. MSYS is much faster than Cygwin for development work, though. Cheers, Simon
On Nov08, Simon Peyton-Jones wrote:
| > Windows and Haskell is not a well travelled route, but if you stray of | > the cuddly installer packages, it gets even worse. | | But it shouldn't. Really it shouldn't. Even though Windows is not my | preferred platform, it is by no means different enough to warrant such | additional complexity. Plus, GHC is developed at Microsoft, and the | currently most featureful Haskell IDE is on Windows...
Over the summer, I was hacking on GHC, using a Vista machine as my primary development box. I was only building basic GHC and not any extra libraries, so my scenario was less complicated than described above. However, here are some resources that might be useful: - The instructions on the GHC wiki worked for me: http://hackage.haskell.org/trac/ghc/wiki/Building Basically, you need to install mingw and msys so you can pretend you're on linux, and then the build is the same as on linux (you need binaries for a previous GHC, Happy, Alex, ...). Except that you need to pass a few options to ./configure, as described a ways down this page (I missed this the first time): http://hackage.haskell.org/trac/ghc/wiki/Building/Windows - I did find that the current darcs HEAD was more likely to be temporarily broken on Windows than on linux (less travelled). I sometimes found it helpful to compare the behavior I saw with the transcript of the BuildBot: http://darcs.haskell.org/buildbot/head/ E.g. the x86 Windows head fast build. If you click on 'stdio', you get the command run for each step as well as the output. In fact following along with each step of the buildbot probably isn't such a bad way to get GHC built in the first place if you're having trouble. -Dan
On Thu, 2007-11-08 at 18:34 +0000, Andrew Coppin wrote:
Neil Mitchell wrote:
Windows and Haskell is not a well travelled route, but if you stray of the cuddly installer packages, it gets even worse.
Is that why Cabal packages never ever install on Windows?
Could you be more specific what your problems are?
Thomas Schilling wrote:
On Thu, 2007-11-08 at 18:34 +0000, Andrew Coppin wrote:
Neil Mitchell wrote:
Windows and Haskell is not a well travelled route, but if you stray of the cuddly installer packages, it gets even worse.
Is that why Cabal packages never ever install on Windows?
Could you be more specific what your problems are?
Not to the point that anybody is likely to be able to help me... 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 However, having so far tried this with not less than 3 different packages downloaded from Hackage, not one single one has ever worked. I suppose it's possible that I just happened to pick 3 packages that all have something wrong with them and normally it would work just fine... but all I've ever seen it do it fail. I tried to install HaXmL. It seemed to install, yet GHC insisted it wasn't installed. I can't remember what the second thing was, sorry. I tried to install the SDL binding; it choked because it can't find "sh". (Which, no, you won't. It's Windows. We don't have anything that advanced yet.) In that case, I believe there are some additional Windows-specific instructions, which I haven't got round to wading through just yet. (Something about fiddling with some of the configuration files manually before starting. I thought that's what Cabal itself was supposed to do, but anyway.) OK, so I'm being a little over-harsh here. In the 3rd case, there are some extra instructions that are supposed to make it work - and who knows, maybe when I go try them SDL will work perfectly. But so far, 0 out of 3 isn't very impressive. I had assumed that I'm just doing something wrong, or it isn't documented very well or something. But now I'm just wondering if it hasn't been tested on Windows very much... 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. (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...)
andrewcoppin:
Thomas Schilling wrote:
On Thu, 2007-11-08 at 18:34 +0000, Andrew Coppin wrote:
Neil Mitchell wrote:
Windows and Haskell is not a well travelled route, but if you stray of the cuddly installer packages, it gets even worse.
Is that why Cabal packages never ever install on Windows?
Could you be more specific what your problems are?
Not to the point that anybody is likely to be able to help me...
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
I usually install as a user, and into my home directory, so the following just works for the 100-odd haskell packages from hackage i have installed currently: runhaskell Setup configure --user --prefix=$HOME runhaskell Setup make runhaskell Setup install --user If that doesn't work, please report it to the author, and the libraries list, possibly the cabal list. Drop by the IRC channel, we solve problems in real time :) -- Don
Don Stewart wrote:
andrewcoppin:
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
I usually install as a user, and into my home directory, so the following just works for the 100-odd haskell packages from hackage i have installed currently:
runhaskell Setup configure --user --prefix=$HOME runhaskell Setup make runhaskell Setup install --user
If that doesn't work, please report it to the author, and the libraries list, possibly the cabal list. Drop by the IRC channel, we solve problems in real time :)
...there's a libraries list? (And a Cabal list??) Well, IRC sounds faster. Next time I actually have the nerve to install something with Cabal, I'll drop in. ;-) [Unless it actually works of course. In fact, no, I'll drop in anyway...]
On Fri, Nov 09, 2007 at 07:38:28PM +0000, Andrew Coppin wrote:
...there's a libraries list? (And a Cabal list??)
On Thu, 2007-11-08 at 22:04 +0000, Andrew Coppin wrote:
Is that why Cabal packages never ever install on Windows?
Could you be more specific what your problems are?
Not to the point that anybody is likely to be able to help me...
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.
However, having so far tried this with not less than 3 different packages downloaded from Hackage, not one single one has ever worked. I suppose it's possible that I just happened to pick 3 packages that all have something wrong with them and normally it would work just fine... but all I've ever seen it do it fail.
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.
OK, so I'm being a little over-harsh here. In the 3rd case, there are some extra instructions that are supposed to make it work - and who knows, maybe when I go try them SDL will work perfectly. But so far, 0 out of 3 isn't very impressive. I had assumed that I'm just doing something wrong, or it isn't documented very well or something. 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.
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.
(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) Duncan
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...
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
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@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
On Thu, 2007-11-08 at 08:56 +0100, Arthur van Leeuwen wrote:
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.
Ah yes.
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.
I hates automake and autoconf :-) It does amaze me that while the output of autoconf/automake is highly portable, running autoconf & automake is so incredibly fragile. It seems to fail fairly randomly even across different linux distros.
Yeah, if you make sure not to have any binaries in paths with embedded spaces... ;)
Yes, another problem with shell scripts / make / autoconf etc. The built installer can be installed anywhere, but building from source requires no spaces. That's another issue using Cabal should solve. Cabal always calls rawSystem so there are no quiting issues.
No. It actually installed. However, building binaries against the installed gtk2hs then fails with a linker error...
Oh. :-( Actually that might be due to registration stuff too.
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.
Right, the problem is both msys/mingw because they're hard to install and autoconf/automake because they're a pain. Using Cabal to build Gtk2Hs will allow us to get rid of both.
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...
Who do you think would decide what is stable? How would that information be communicated? Perhaps what you really want is a standard platform that's been tested as a unit. Perhaps what we want is automated feedback reporting build successes and failures so we can inform people selecting packages about popularity, maturity and compatibility.
Ah, yes, that is a thing. However, googling for alex does not lead me to hackage, nor does the alex webpage. Ditto for Happy.
We need to make it the first place to look. We're trying to get to the stage where we can deploy cabal-install widely, then you'd try: $ cabal list foo and only if it was not available then you'd go and google for the package. Help with improving cabal-install from anyone would be much appreciated and very useful. Quite a few people have been trying it out and giving us feedback on how they would expect it to behave. So we know mostly where we need to go, we just need help in terms of development time to get there.
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.
No probs. Duncan
participants (11)
-
Andrew Coppin -
Arthur van Leeuwen -
Dan Licata -
Don Stewart -
Duncan Coutts -
Neil Mitchell -
Peter Hercek -
Simon Marlow -
Simon Peyton-Jones -
Stefan O'Rear -
Thomas Schilling