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.
--
/\ / | [EMAIL PROTECTED] | 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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
