OK, so let's step back a bit.

I think Luc's right in two senses, first that we need to understand what the 
user-facing problem is, and second what is technical problem lying at the heart 
of user-facing problem.

In your first message you said:

> 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).

OK let me get this straight.  Is the user-facing problem here that installing 
wxHaskell for use in a sandbox environment is impossible or just very 

My understanding is that it's the latter: namely because you have to jump 
through three extra hoops:

w0. install wxWidgets
w1. update PATH to point to wxWidgets?
w2. install wx-config
w3. set up WXWIN, WXWIN, PATH environment variables
w4. install wxdirect
w5. then cabal install wx (which grabs wxcore and wxc automatically)

Contrast with four steps in gtk2hs

g0. install gtk
g1. update PATH to point to gtk?
g2. install gtk2hs-buildtool
g3. cabal install gtk

Do I have this right, first of all?

I had some longer comments on the technical issues.  I think we may be need to 
step back a bit and peel apart the fundamental issues first (C++, shared 
libraries, other?) but first let's make sure we understand what the user-facing 
problem really is.  Is it impossibility or is it hoops?

Eric Kow <http://erickow.com>

Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
wxhaskell-devel mailing list

Reply via email to