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 <[EMAIL PROTECTED]> 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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ wxhaskell-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
