WxHaskell/Mac: Difference between revisions
(→Notes) |
(GHC 7.0.4 is 2011.4.0.0, not 2011.2.0.0) |
||
Line 37: | Line 37: | ||
|Snow Leopard (10.6.8), Xcode 3.2.6 | |Snow Leopard (10.6.8), Xcode 3.2.6 | ||
|7.0.4 | |7.0.4 | ||
|2011. | |2011.4.0.0 | ||
|2.9.3 (MacPorts) | |2.9.3 (MacPorts) | ||
|0.90 (see notes) | |0.90 (see notes) |
Revision as of 11:37, 18 April 2012
Installing on MacOS X
- Install the Developer Tools
- Install wxWidgets 2.9 by hand (HomeBrew makes this easy:
brew install wxmac --devel
; or on Lion, possiblybrew install wxmac --use-llvm --devel
) - Check your path to make sure you are using your wxWidgets and not the default Mac one
cabal install wx cabal-macosx
Known working configurations
Date | Arch | OS/XCode | GHC | Haskell Platform | wxWidgets | wxHaskell |
---|---|---|---|---|---|---|
2012-04 | Intel 64-bit | Lion (10.7.3), XCode 4.3 | 7.4.1 | 2011.3.0.0 | 2.9.3 (HomeBrew) | 0.90 (see notes) |
2012-04 | Intel 64-bit | Lion (10.7.3), Xcode 4.3 | 7.0.4 | 2.9.3 (HomeBrew) | 0.90 | |
2012-04 | Intel 32-bit | Snow Leopard (10.6.8), Xcode 3.2.6 | 7.0.4 | 2011.4.0.0 | 2.9.3 (MacPorts) | 0.90 (see notes) |
Notes
These notes tend to be a bit ephemeral and are thus dated to help you figure out if they may still apply or not.
- 2012-04-17: The MacPorts version of wxWidgets 2.9.3 can be used, though I added a few flags to the Portfile. I seem to have a few issues with functionality, but they may not necessarily be related to MacPorts.
- 2012-04-14: On MacOS X Lion, to install wxWidgets 2.9 with HomeBrew, you may need to run
brew install wxmac --use-llvm --devel
Using wxHaskell on MacOS X platforms
Even though graphical applications on MacOS X look great, it is a still a developers nightmare to get them working :-). Furthermore, the MacOS X port of wxWidgets is the least mature and still has some quirks. This page describes how to circumvent some of the pitfalls.
- Graphical applications generated with GHC do not work if executed directly ; they need to be upgraded into MacOS X applications. See cabal-macosx to automate this. It can be integrated with Cabal and/or used as a standalone `macosx-app` script.
Due to complicated MacOS X restrictions, graphical wxHaskell applications do not work directly when used from GHCi. Fortunately, Wolfgang Thaller has kindly provided an ingenious Haskell module that solves this problem. Just import the (compiled) module EnableGUI in your program and issue the following command to run main from your GHCi prompt:
> enableGUI >> main
Compiling and using enableGUI needs some command line flags:
> ghc -XForeignFunctionInterface -c EnableGUI.hs > ghci -framework Carbon HelloWorld.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading object (framework) Carbon ... done final link ... done [2 of 2] Compiling Main ( Main.hs, interpreted ) Ok, modules loaded: Main, EnableGUI. *Main> enableGUI *Main> main
The dynamic link libraries used by wxHaskell can not always be found. If your application seems to start (the icon bounces) but terminates mysteriously, you need to set the dynamic link library search path to the wxHaskell library directory. For example:
> setenv DYLD_LIBRARY_PATH /usr/local/wxhaskell/lib
or
> setenv DYLD_LIBRARY_PATH $HOME/.cabal/local/lib/wxhaskell-0.11.0/lib
Troubleshooting
See WxHaskell/Troubleshooting for help getting your wxhaskell applications running
- Why do I have to
macosx-app
my binaries?- 2009-04-01: we don't know for sure yet.
macosx-app
is just a shell script that runsRez
and also creates an application bundle. If you are a MacOS developer, especially a wxWidgets one, we would love some help answering this question. - 2009-11-24: Please see also Andy Gimblett's cabal-macosx project
- 2009-04-01: we don't know for sure yet.