[Haskell-cafe] I still cannot seem to get a GUI working under Windows.

[Jeremy O'Donoghue]

Apologies folks, rant coming up...

On Wed, 29 Sep 2010 22:02 +0100, "Andrew Coppin"
<andrewcoppin at btinternet.com> wrote:
>   On 29/09/2010 07:33 PM, Steve Schafer wrote:
> > The issue isn't that there aren't a lot of Windows developers who have
> > an interest in Haskell+GUI development. The issue is that nearly every
> > Windows developer who looks into Haskell+GUI says, "This stuff sucks,"
> > and walks away, because they're interested in developing applications,
> > not wrestling with GUI toolkits.
> 
> Yep, that's the one.

[snip for brevity]
 
> How do you do that in Haskell? Well, you can either install and 
> configure a complete Unix emulator and then compile wxHaskell from 
> source (?!), or you can use Gtk2hs, which still requires you to manually 
> install and configure GTK+ and compile the entire library from source 
> code. And even then, your developed application will only run on Windows 
> boxes that have GTK+ installed (i.e., none of them). All of which is a 
> far cry from "install IDE, click some buttons, run the wizzard, job
> done".
> 
> Then again, let us not claim that this is only a problem for GUI stuff. 
> If you want to access a database, or run compression algorithms, or play 
> sound, or do absolutely anything else which requires talking to C-land, 
> you've going to have to face a world of pain on Windows.

As one of the people trying desperately to make this better on Windows
(i.e. as wxHaskell maintainer...), I'd have to add that aspects of GHC
make this much harder than I'd like.

Take the specific case of wxHaskell, since I'm familiar with it. The
'requirement' is pretty straightforward in principle. What I want is:

1) Make wxHaskell easy to build and install on all platforms.
2) Make wxHaskell work in GHCi for 'exploratory' programming as well as
for compiled executables

Bear in mind that as I have a (very) demanding day job and a young
family, I actually have no more than 3-4 hours a week (at best) to spend
maintaining wxHaskell. Bear in mind also that my interest in wxHaskell
was always to be able to develop software in Haskell, not fight with
linkers and build systems (I get enough of that at work, thanks). While
that's my personal problem, and others may not have the same issues, so
please feel free to not care at all, it's worth bearing in mind...

wxHaskell consists of a set of C bindings over the C++ core of
wxWidgets. Broadly speaking, these unmangle the C++ names and do little
else. 

Now, wxWidgets, being C++, links against libstdc++ (a not unreasonable
requirement). MinGW, which is the underlying framework used by GHC only
knows how to link libstdc++ statically, but the way cabal constructs
link commands means that when wxcore gets loaded, GHCi attempts to load
libstdc++ dynamically. You're dead.

OK. Next step is to build the C wrapping as a separate DLL. In this case
libstdc++ can be statically linked with the wxc DLL and the dependency
on libstdc++ can go away. Trouble is, you now need to construct a C++
build system for a DLL in Cabal. Lots more custom build hooks, and some
of what goes on under the hood is magic. However, eventually you get
something which builds a DLL with only mildly sucky dependency
management. Problem is now to pick this up in GHC and GHCi. After
several weeks I still don't have the right stanza to invoke the linker.

Next make sure that this all coexists with the inevitable several
instances of MinGW, Cygwin and others which exist on the machine of a
typical developer who uses Open Source code - ideally throwing in a nice
mix of 32 and 64 bit variants of same, and with completely random path
orderings.

What would work best for me is something which is, I think, conceptually
quite simple: allow Cabal to pull DLLs (or .so or .dylib or wwhatever)
from some standard place (maybe in the Cabal tarball for a package), and
add them to the link lines correctly, plus put them somewhere GHC will
know about them for the future. This means that I, as wxHaskell
developer, could build 'known good' wxWidgets DLLs, plus a known good
wxc DLL and package them with wxcore, and end users would stop needing
to care about building for themselves. 

This would let me use more appropriate build systems for the non-Haskell
components without requiring users to download and install an insane
number of libraries and developer tools - IOW, it puts the burden of
building libraries on the library maintainer, but takes away the burden
on the library maintainer of making this work for everyone else's
machines, and documenting it, keeping the build documentation up to date
and simple enough for people who don't want to become C or C++
developers to understand!

As it is, in order to maintain what is a conceptually simple set of
bindings, I need to become a deep expert in:

- Customizing Cabal build hooks
- How GHC and GHCi construct their link stanzas (is this documented
anywhere?)
- Installing and using MinGW - since this the only thing GHC guarantees
to have available, so I'd like to
  use it to make life easier for others (much as I like gcc on Unix
  platforms, it's a long way from working
  as I'd expect on Windows)
- MinGW quirks (like the inability to link libstdc++ as a DLL, and it's
strange notion of import libraries)

It would be nice if GHC and GHCi had a better story in respect of DLLs
on Windows, but I accept that at least part of the problem is the
underlying dependency on MinGW, so it's probably hard to solve this one.

> It seems that because this stuff is such a PITA on Windows, nobody uses 
> Haskell on Windows. And since nobody uses Haskell on Windows, nobody is 
> fixing these problems. So they just stay here, forever.

Actually, I don't completely agree. I think that the issue is that
making things better on Windows (and likely OS X as well) requires
co-ordinated and agreed action across a number of areas. This means
getting a moderate number of people, most of whom give up their time and
effort for free, and for the good of the community, to agree on what is
needed and to prioritize it in a co-ordinated way. The action needed by
any individual might be relatively small, but without community
agreement and action, the end goal cannot be achieved.

Some areas probably need to be addressed by people whose primary focus
*is* Linux (or other Unix) because that's what they use on a daily
basis. They might well prefer to spend their valuable time on goals
closer to their own hearts than in making life better on Windows, but
the fact is that a better sotry on Windows probably does require some
work in areas like GHC and Cabal, whose maintainers are, I suspect,
mainly Linux users.

Of course, the fact that this is all in the area of building and linking
code, a notoriously revolting and unrewarding area of software
development, and far less sexy than, say, inventing a morphism more
unpronounceable than the Zygohistomorphic, probably doesn't help.

Sorry for the rant, but just my $0.02

Regards
Jeremy
-- 
  Jeremy O'Donoghue
  jeremy.odonoghue at gmail.com