Personal tools

WxHaskell/Development/Environment

From HaskellWiki

< WxHaskell | Development(Difference between revisions)
Jump to: navigation, search
(Building and testing wxHaskell)
(Purpose of files which will need to be updated: ./wxcore/wxcore.cabal -> ./wxc/wxc.cabal)
 
(10 intermediate revisions by one user not shown)
Line 4: Line 4:
 
== Obtaining wxWidgets ==
 
== Obtaining wxWidgets ==
  
Firstly, see [[WxHaskell/Building#Getting_wxWidgets|Getting wxWidgets]] and [[WxHaskell/Building#Building_wxWidgets_.28usually_optional.29|Building wxWidgets]].
+
Firstly, see [[WxHaskell/Linux]], [[WxHaskell/Mac]] or [[WxHaskell/Windows]].
  
Note that wxHaskell is currently between wxWidgets 2.8 and the development 2.9 release, so it pays well to ensure new code will work with both versions. It is possible to safely co-habit two version of wxWidgets. When you do wxHaskell will build against whichever version is returned by <code>wxconfig --version</code>, on Linux you can change which version you build wxHaskell against by follow steps similar to this (this should be easier):
+
Note that wxHaskell currently supports the wxWidgets 2.9 and the 3.0 release, so it pays well to ensure new code will work with both versions. It is possible to safely co-habit two versions of wxWidgets. When you do, wxHaskell will build against whichever version is returned by <code>wx-config --version</code>, on Linux you can change which version you build wxHaskell against by follow steps similar to this (this should be easier):
 
<pre>$ wx-config --version
 
<pre>$ wx-config --version
2.8.12
+
2.9.5
 
$ whereis wx-config
 
$ whereis wx-config
 
wx-config: /usr/local/bin/wx-config
 
wx-config: /usr/local/bin/wx-config
 
$ ls -l /usr/local/bin/wx-config
 
$ ls -l /usr/local/bin/wx-config
lrwxrwxrwx 1 root root 41 2011-09-14 21:20 /usr/local/bin/wx-config -> /usr/local/lib/wx/config/gtk2-unicode-debug-2.8
+
lrwxrwxrwx 1 root root 41 2011-09-14 21:20 /usr/local/bin/wx-config -> /usr/local/lib/wx/config/gtk2-unicode-debug-2.9
 
$ sudo rm /usr/local/bin/wx-config
 
$ sudo rm /usr/local/bin/wx-config
$ sudo ln -s /usr/local/lib/wx/config/gtk2-unicode-2.9 /usr/local/bin/wx-config
+
$ sudo ln -s /usr/local/lib/wx/config/gtk2-unicode-3.0 /usr/local/bin/wx-config
 
$ wx-config --version
 
$ wx-config --version
2.9.2</pre>
+
3.0.2</pre>
 +
 
 +
On Windows, the used wxWidgets version can be changed by changing the environment variable WXWIN:
 +
<pre>
 +
  Set WXWIN=C:\Libs\wxWidgets\3.0.2
 +
</pre>
 +
(Avoid spaces in path names.)
  
 
== Building and testing wxHaskell ==
 
== Building and testing wxHaskell ==
Line 22: Line 28:
 
Firstly, see [[WxHaskell/Building#Source_Release|Source Release]], however it is recommended that you do the following, instead of following the instructions there to build each component:
 
Firstly, see [[WxHaskell/Building#Source_Release|Source Release]], however it is recommended that you do the following, instead of following the instructions there to build each component:
  
Use [[Cabal-dev]] to isolate your development code from stable wxHaskell packages you may have obtained from [[Hackage]].  
+
Use a [[Cabal-install]] sandbox to isolate your development code from stable wxHaskell packages you may have obtained from [[Hackage]].  
You can then install your development version of wxHaskell into a separate [[Cabal-dev]] [http://www.haskell.org/ghc/docs/7.0.3/html/users_guide/packages.html package database] (which will be under <code>./cabal-dev/packages-7.0.3.conf/</code>).
+
You can then install your development version of wxHaskell into a separate [http://www.haskell.org/ghc/docs/latest/html/users_guide/packages.html package database] (which will be under <code>.cabal-sandbox/i386-windows-ghc-7.8.3-packages.conf.d</code>(the name is depending on architecture and GHC version, of course)).
To do this enter the root wxHaskell directory (the one you obtained with <code>darcs</code> from http://code.haskell.org/wxhaskell/) and enter the following:
+
To do this, enter the root wxHaskell directory (the one you obtained from the current repository) and enter the following:
  
<pre>cabal-dev install ./wxdirect ./wxc ./wx ./wxcore</pre>
+
<pre>
 +
cabal sandbox init
 +
cabal install ./wxdirect ./wxc ./wx ./wxcore
 +
</pre>
  
Notes:
+
Note:
* Previously this page suggested using <code>add-source</code>, but packages added in such a way will not be recompiled when the source given is changed, this is discussed [https://github.com/creswick/cabal-dev/blob/master/README.md in the "Using a sandbox-local Hackage" section].
+
* If changes are made to wxdirect, the shell PATH environment variable should contain <code>.cabal-sandbox/bin</code> before any other location where a wxdirect executable can be found.
* If changes are made to wxdirect, the shell PATH environment variable should contain <code>cabal-dev/bin</code> before other locations where a(nother) wxdirect executable can be found.
+
  
 
You may then build against your development install thus:
 
You may then build against your development install thus:
<pre>ghc -package-conf /path/to/wxhaskell/cabal-dev/packages-7.0.3.conf/ --make MyTestCode.hs</pre>
+
<pre>cabal exec ghc ./samples/wxcore/BouncingBalls.hs</pre>
  
 
== Wrapping new wxWidgets functionality ==
 
== Wrapping new wxWidgets functionality ==
  
Note: Inspiration for this comes from [http://www.mail-archive.com/wxhaskell-devel@lists.sourceforge.net/msg00630.html this email].
+
Note: Inspiration for this comes from [http://www.mail-archive.com/wxhaskell-devel@lists.sourceforge.net/msg00630.html this email].  
  
 
=== Purpose of files which will need to be updated ===
 
=== Purpose of files which will need to be updated ===
Line 44: Line 52:
 
; ./wx/src/Graphics/UI/WX/Controls.hs : 'High' level Haskell wrapper. You place constructors which are property-aware here. In most respects this is straightforward except that you need to work out what instances are appropriate to a your new functionality. You may want to look [http://wewantarock.wordpress.com/2010/01/11/custom-controls-in-wxhaskell-part-3/ here] for some more information about implementing <code>Attribute</code> instances.
 
; ./wx/src/Graphics/UI/WX/Controls.hs : 'High' level Haskell wrapper. You place constructors which are property-aware here. In most respects this is straightforward except that you need to work out what instances are appropriate to a your new functionality. You may want to look [http://wewantarock.wordpress.com/2010/01/11/custom-controls-in-wxhaskell-part-3/ here] for some more information about implementing <code>Attribute</code> instances.
  
; ./wxcore/src/eiffel/wx_defs.e : An ugly piece of legacy from the days when wxcore was derived from an Eiffel wrapping of wxWidgets. Event identifiers need to be defined here. (Jeremy: I *really* want to get rid of this file one day - it serves no purpose to have an Eiffel file these days.)
+
; ./wxc/src/include/wxc.h : This creates the correct type witnesses to map the class Hierarchy.
 
+
; ./wxcore/src/include/wxc.h : This creates the correct type witnesses to map the class Hierarchy.
+
  
; ./wxcore/src/include/wxc_glue.h : This is basically where you need to put the declarations for C++ method wrappers.
+
; ./wxc/src/include/wxc_glue.h : This is basically where you need to put the declarations for C++ method wrappers.
  
 
; ./wxcore/src/haskell/Graphics/UI/WXCore/Events.hs : Your Haskell event handler code goes here. You need one function which reacts to events, which accepts an event handler as a parameter and a function which will fetch your event handler (you need this mostly in case you want to hook a further event handler which doesn't kill the one already present).
 
; ./wxcore/src/haskell/Graphics/UI/WXCore/Events.hs : Your Haskell event handler code goes here. You need one function which reacts to events, which accepts an event handler as a parameter and a function which will fetch your event handler (you need this mostly in case you want to hook a further event handler which doesn't kill the one already present).
  
; ./wxcore/src/cpp/XXX.cpp : Implementations of the wrappers. The old <code>eljXXX</code> naming convention for these files really isn't necessary any more. I'd suggest calling the implementation <code>mynewfunctionality.cpp</code> or something like that.
+
; ./wxc/src/cpp/XXX.cpp : Implementations of the wrappers. The old <code>eljXXX</code> naming convention for these files really isn't necessary any more. I'd suggest calling the implementation <code>mynewfunctionality.cpp</code> or something like that.
  
; ./wxcore/src/cpp/eljrc.cpp : Constructs functions for geting control pointers out of window hierarchies created from XRC files.  
+
; ./wxc/src/cpp/eljrc.cpp : Constructs functions for getting control pointers out of window hierarchies created from XRC files.  
  
; ./wxcore/src/cpp/eljevent.cpp : Wrap up event values as functions. I tend to do this instead.
+
; ./wxc/src/cpp/eljevent.cpp : Wrap up event values as functions. I tend to do this instead.
  
; ./wxcore/src/cpp/defs.cpp : Another way of wrapping up event values as functions. (Jeremy: I don't tend to do this, and I don't think anyone has for years.).
+
; ./wxc/src/cpp/defs.cpp : Another way of wrapping up event values as functions. (Jeremy: I don't tend to do this, and I don't think anyone has for years.).
  
; ./wxcore/wxcore.cabal : Ensure you add <code>mynewfunctionality.cpp</code> to <code>c-sources</code> in <code>./wxcore/wxcore.cabal</code>
+
; ./wxc/wxc.cabal : Ensure you add <code>mynewfunctionality.cpp</code> to <code>c-sources</code> in <code>./wxc/wxc.cabal</code>
  
  
 
[[Category:wxHaskell]]
 
[[Category:wxHaskell]]

Latest revision as of 19:14, 31 January 2016

Contents

[edit] 1 Overview

This page is intended to provide information for those wishing to work on the wxHaskell library, specifically creating and maintaining an environment in which to do so.

[edit] 2 Obtaining wxWidgets

Firstly, see WxHaskell/Linux, WxHaskell/Mac or WxHaskell/Windows.

Note that wxHaskell currently supports the wxWidgets 2.9 and the 3.0 release, so it pays well to ensure new code will work with both versions. It is possible to safely co-habit two versions of wxWidgets. When you do, wxHaskell will build against whichever version is returned by wx-config --version, on Linux you can change which version you build wxHaskell against by follow steps similar to this (this should be easier):

$ wx-config --version
2.9.5
$ whereis wx-config
wx-config: /usr/local/bin/wx-config
$ ls -l /usr/local/bin/wx-config
lrwxrwxrwx 1 root root 41 2011-09-14 21:20 /usr/local/bin/wx-config -> /usr/local/lib/wx/config/gtk2-unicode-debug-2.9
$ sudo rm /usr/local/bin/wx-config
$ sudo ln -s /usr/local/lib/wx/config/gtk2-unicode-3.0 /usr/local/bin/wx-config
$ wx-config --version
3.0.2

On Windows, the used wxWidgets version can be changed by changing the environment variable WXWIN:

  Set WXWIN=C:\Libs\wxWidgets\3.0.2

(Avoid spaces in path names.)

[edit] 3 Building and testing wxHaskell

Firstly, see Source Release, however it is recommended that you do the following, instead of following the instructions there to build each component:

Use a Cabal-install sandbox to isolate your development code from stable wxHaskell packages you may have obtained from Hackage. You can then install your development version of wxHaskell into a separate package database (which will be under .cabal-sandbox/i386-windows-ghc-7.8.3-packages.conf.d(the name is depending on architecture and GHC version, of course)). To do this, enter the root wxHaskell directory (the one you obtained from the current repository) and enter the following:

cabal sandbox init
cabal install ./wxdirect ./wxc ./wx ./wxcore

Note:

  • If changes are made to wxdirect, the shell PATH environment variable should contain .cabal-sandbox/bin before any other location where a wxdirect executable can be found.

You may then build against your development install thus:

cabal exec ghc ./samples/wxcore/BouncingBalls.hs

[edit] 4 Wrapping new wxWidgets functionality

Note: Inspiration for this comes from this email.

[edit] 4.1 Purpose of files which will need to be updated

Although the specific modifications required depends on the complexity of the wxWidgets functionality you are wrapping, this list serves to document the relationship between the files and what purpose they serve.

./wx/src/Graphics/UI/WX/Controls.hs 
'High' level Haskell wrapper. You place constructors which are property-aware here. In most respects this is straightforward except that you need to work out what instances are appropriate to a your new functionality. You may want to look here for some more information about implementing Attribute instances.
./wxc/src/include/wxc.h 
This creates the correct type witnesses to map the class Hierarchy.
./wxc/src/include/wxc_glue.h 
This is basically where you need to put the declarations for C++ method wrappers.
./wxcore/src/haskell/Graphics/UI/WXCore/Events.hs 
Your Haskell event handler code goes here. You need one function which reacts to events, which accepts an event handler as a parameter and a function which will fetch your event handler (you need this mostly in case you want to hook a further event handler which doesn't kill the one already present).
./wxc/src/cpp/XXX.cpp 
Implementations of the wrappers. The old eljXXX naming convention for these files really isn't necessary any more. I'd suggest calling the implementation mynewfunctionality.cpp or something like that.
./wxc/src/cpp/eljrc.cpp 
Constructs functions for getting control pointers out of window hierarchies created from XRC files.
./wxc/src/cpp/eljevent.cpp 
Wrap up event values as functions. I tend to do this instead.
./wxc/src/cpp/defs.cpp 
Another way of wrapping up event values as functions. (Jeremy: I don't tend to do this, and I don't think anyone has for years.).
./wxc/wxc.cabal 
Ensure you add mynewfunctionality.cpp to c-sources in ./wxc/wxc.cabal