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