Re: [wxhaskell-users] wxHaskell Status

[Jeremy O'D. <jer...@gm...>]

Hi Wouter,

Some long overdue updates on what I am doing (and why) in-line. By the
way, if anyone thinks that whay I am doing is the wrong way to go,
please chime in (preferably with a constructive alternative).

On 03/12/06, Wouter Swierstra <ws...@cs...> wrote:
>
> I was curious what the status of wxhaskell is now. I realize that
> there's been a lot of progress and you guys have set up a new darcs
> repository. Is there a new release that has been tested on different
> platforms and is known to work well with certain versions of ghc and
> wxWidgets?

We're not yet ready for a release. The sources out of darcs can be
successfully built on Linux/OSX/Windows (I can personally vouch for
OSX and Windows) but there are enough wrinkles that stop it from
working 'out of the box' that it can't really be called 'ready'.

> Will there be binaries available any time soon?

Not until we are confident about making something which 'always works'.

> A lot of
> people seem to be having trouble with disable/enable unicode - now
> would be a good time to update the homepage, bring the build
> instructions up to date, and get a new version out there.

The main issue seems to be that although the wxHaskell sources
themselves are very solid indeed (and Eric has been doing a superb job
in ensuring the quality of what goes into darcs), it's too easy to get
the build wrong and end up with something which appears to compile and
link, but then does not work.

OS X seems to be particularly susceptible to this, and after the
problems Stefan Holdermans reported a week or two back, I have
diverted into looking into why the OS X build is so fragile. I don't
yet have a reason,but I'm definitely seeing unexpected linker
behaviour with some build scenarios which I am trying to get to the
bottom of. We were able to get Stafan going by creating a statically
linked build variant, but I would like to understand why the
dynamically linked version is so sensitive to the options used to
build wxWidgets.

Before I was diverted onto the OS X build, I was looking at
Cabalization (assuming that such a word exists...)

One of the key issues raised by GHC 6.6 was that it breaks the
wxHaskell build system due to the way in which the wxc, wxCore and wx
libraries are built and installed. There is a work-around in darcs
(from shelarcy - basically do the build in several stages), but this
is not really satisfactory for the longer term.

My original idea was to do the whole build with Cabal, but this really
isn't an option for the wxc wrapper as Cabal is poorly equipped for
building complex C codebases (not really a criticism - it is the
*Haskell* Cabal!).

I've therefore moved to separate the build of wxc from the remainder
of wxHaskell. This is probably sensible as wxc is not really tied in
any way to Haskell, and should probably stand alone in the longer term
(c.f. wxc.sourceforge.net, which exists, but is not currently very
active).

This means splitting the wxHaskell makefile so that it contains only
the parts needed to build wxc, which I have done for OS X and Unix (OK
- it was the easy part, but I still want to be sure about OS X
stability), and am in the process of doing for Windows (I'm getting
rid of the VC++ project files which required the user to edit a
machine-generated file which says 'do not edit' at the top and
replacing with an NMAKE makefile). This should make Windows builds
much easier to do as the bits which might need to be edited are all in
one place (can't auto-detect on Windows as on Unix, unfortunately). It
will (I think) also have the benefit that it should be possible to
build wxC with only the free versions of the Microsoft tools.

One note I should make regarding the wxC parts: the wxc maintainers on
Sourceforge have not chosen to use Make.  They have, instead, chosen
to use Geant which is, I think, an Eiffel-based 'Ant-alike'. I can't
agree with this, and prefer to have a few dependencies as possible for
the build system. The wxC library needs no more than a C++ compiler
and make to build it; anyone likely to be interested in wxC will
already have these. Using any other build system just multiplies
dependencies and ensures that anyone interested is more likely to give
up. Cabal is OK for Haskell-specific parts as it's part of the
distribution. Anyway,I already know and loathe make ;-)

Last part, which I haven't finished, is Cabalization of the Haskell
parts, which should make the Haskell build much more maintainable. The
hard bit is wxDirect (or rather, running it over wxC library to
generate the WX.Core sources) in Cabal. This requires me to write a
bit more code than I expected, and so it's taking some time.

Anyway, I've probably gone completely off-topic in answering you, but
that's what I am getting up to.

Regards
Jeremy