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