Simpler would be fantastic, but there are technical reasons for the current setup. If you can meet the same goals whilst delivering an easier install experience (or boldly cut off goals that can be better understood as wrongheaded), more power to ya!

* wxc - C++ to C wrapper. Uses make (or can be easily persuaded to do so?) to enable collaboration with non Haskell projects. I may be wrong here, wasn't involved in recent round of simplifications

* wxdirect - generates code from header files? 

* wxcore - C to Haskell. partly auto generated by wxdirect. This is what makes it vaguely possible to run the wxWidgets treadmill

* wxc - the easy part. Nice mid level completely static Haskell. Nice to have a part people can hack on that without low level concerns 

With this sort if layering in mind, each layer providing some goals, can we do anything to improve the situation?



On 30 May 2013, at 21:16, Blair Archibald <mrblairarchibald@gmail.com> wrote:

I agree that the current deployment system for wxHaskell is not ideal and we should probably look into changing it. Does anyone have any ideas as to how we could go about this?

The logical first step seems to be to combine the 3 packages (wxcore, wx, wxc) into some form of singly installed package. I'm a novice when it comes to cabal so not sure how what the effects of such a change could be.

I appreciate that cabal is a great system for installing Haskell packages but perhaps we should provide additional install methods that also come pro-bundled with wxWidgets, this way we can control the version that we ship with - again the issue comes with how to install them on different platforms and in a controlled manner.

These are just a few ideas. I'd be willing to work on additional deployment methods if anyone wants to take this on and needs help (as I say I'm possibly too novice at wxHaskell and Cabal to get this right on my own).

Many thanks,
Blair


On 30 May 2013 19:04, harry <voldermort@hotmail.com> wrote:
Building Gtk2Hs on Windows is very straightforward. After Gtk+ is included
in the path, cabal install gtk2hs-buildtools will install all the
executables needed for building the bindings, but no libraries. cabal
install gtk will then install the library.

OTOH, cabal install wxdirect installs both the helper executable and a
library. 3 other packages then have to be installed, at least one of which
requires environment variables pointing to bits of earlier packages. One
upshot of all this is that it's well nigh impossible to use wxhaskell with
cabal-dev, whereas with gtk2hs it's really easy (install gtk2hs-buildtools
outside the sandbox, then gtk will use it in the sandbox).


------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel