[Haskell-cafe] Building Haskell stuff on Windows

[Duncan Coutts]

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