From: harry <vol...@ho...> - 2013-05-30 18:20:12
|
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). |
From: Blair A. <mrb...@gm...> - 2013-05-30 20:16:51
|
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 <vol...@ho...> 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 > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > |
From: Eric K. <eri...@gm...> - 2013-05-30 20:30:35
|
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 <mrb...@gm...> 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 <vol...@ho...> 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 >> wxh...@li... >> 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 > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel |
From: harry <vol...@ho...> - 2013-05-31 05:35:23
|
Blair Archibald <mrblairarchibald@...> writes: > 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. The first problem is that wxdirect installs both executables and a library - why is that necessary, and is there another way to do it? |
From: Eric K. <eri...@gm...> - 2013-05-31 13:24:08
|
On 31 May 2013 06:34, harry <vol...@ho...> wrote: > The first problem is that wxdirect installs both executables and a library - > why is that necessary, and is there another way to do it? Could you elaborate on this? I'm not 100% sure I follow. Is the issue something related to the wxdirect executable not being available in the sandbox environment? One issue is that wxdirect is used in the build process of the wxcore Setup.hs One thing which I think might help matters is if we had a way for the custom Setup.hs in wxcore to depend on wxdirect. Now one option would be for us to just swallow wxdirect directly into wxcore, making it part of the setup script. There's no particular reason it has to be run as an executable. If not feasible, then we may need something like https://github.com/haskell/cabal/issues/948 -- Eric Kow <http://erickow.com> |
From: Luc T. <luc...@gm...> - 2013-05-31 13:28:26
|
btw, we are already at the solution stage, what is the problem in fact ? what are the typical difficulties that a raise when installing wx ? is it on the C side or on the haskell side ? is it because they have to be fetched separately ? do we have a shared view on where lies the problems ? -- Luc Taesch Envoyé avec Sparrow (http://www.sparrowmailapp.com/?sig) Le vendredi 31 mai 2013 à 15:24, Eric Kow a écrit : > On 31 May 2013 06:34, harry <vol...@ho... (mailto:vol...@ho...)> wrote: > > The first problem is that wxdirect installs both executables and a library - > > why is that necessary, and is there another way to do it? > > > > > Could you elaborate on this? I'm not 100% sure I follow. > > Is the issue something related to the wxdirect executable not being > available in the sandbox environment? > > One issue is that wxdirect is used in the build process of the wxcore Setup.hs > > One thing which I think might help matters is if we had a way for the > custom Setup.hs in wxcore to depend on wxdirect. Now one option would > be for us to just swallow wxdirect directly into wxcore, making it > part of the setup script. There's no particular reason it has to be > run as an executable. > > If not feasible, then we may need something like > https://github.com/haskell/cabal/issues/948 > > -- > 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. > http://p.sf.net/sfu/appdyn_d2d_ap2 > _______________________________________________ > wxhaskell-devel mailing list > wxh...@li... (mailto:wxh...@li...) > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > > |
From: harry <vol...@ho...> - 2013-05-31 15:31:49
|
Eric Kow <eric.kow@...> writes: > Is the issue something related to the wxdirect executable not being > available in the sandbox environment? Yes - executables built in cabal-dev aren't on the path (which is different for each sandbox). If wxdirect only built an executable, I could install it outside of the sandboxes, and it would be available in the path for later use. A similar issue arises with wxc - what exactly is it building, and why is an environment variable needed to find it later? Is it creating a Haskell library, or just creating come C files for use by wxcore? |
From: Eric K. <eri...@gm...> - 2013-05-31 16:16:21
|
OK, I'm studying http://www.haskell.org/haskellwiki/WxHaskell/Windows to update my understanding of the build infrastructure a bit May I ask which environment variables in particular you're referring to? So for the matter of executables not being on the path, two approaches might be (A1) [the frustrated sandboxer] cabal-dev install wxdirect before cabal-dev install your-package. Whilst this would install wxdirect into your sandbox, with at least some versions of cabal-install, it also creates symlinks pointing from ~/.cabal/bin into said sandbox [fact-check?] (A2) [the frustrated sandboxer] like with gtk2hs, install wxdirect universally [I think this is what I do?] (B) [an aspiring wxHaskell hacker] modify wxcore's Setup.hs to use wxdirect as a library of some sort. There's a bit of a complication here in that we're actually faking the dependency on wxdirect: we're claiming that wxcore depends on wxdirect when the case is more that the Setup.hs script used by wxcore uses wxdirect. There might be some unpredictable cabalisation problems that arise due to the current limitation I pointed to earlier https://github.com/haskell/cabal/issues/948 --- So we have: - wxWidgets C++ - wxc (the C interface) - wxcore (autogenerated Haskell [FFI stuff] + low-ish level Haskell calling the FFI stuff) - wx (nicer Haskell) In the case of wxc what we have are a bunch of C++ files that expose a C interface to wxWidgets. No fancy code generation, no Haskell. Sure there are folks who would love for wxc to be completely automatically generated (as would I), but nobody has gotten around to it. The wxc build script needs to know where WxWidgets lives so that it knows what libraries to link against (it calls the wx-config program for this, which alas doesn't really exist on Windows and you have to very painfully fetch a stand-in for), hence WXWIN The autogenerated parts of wxcore are I think Haskell wrappers around wxc [created by wxdirect]. The input to this process is just the handwritten wxc header files, which wxcore Setup finds by asking Cabal: https://github.com/atzedijkstra/wxHaskell/blob/master/wxcore/Setup.hs#L37 I notice that the wiki mentions WXC_VERSION and putting something like %CABAL_DIR%\wxc-%WXC_VERSION%\%GHC_VERSION% in the PATH. Yuck. This should “only” be needed when we actually want to run something, so that the Windows runtime linking stuff can do its magic with wxc.dll Once upon a time wxc/wxcore were a single package. And we relatively recently split them apart (I think to some rejoicing?) which made the wxcore build process a lot simpler (?). I'm afraid I'm going to have to put this down now so I can't research our decision to make the split, but I'd encourage anybody who wants to work on wxHaskell to study the evolution of this. Sorry for the mess folks! I think the build situation has improved a lot over the years. But we still have a way to go. I agree that fewer hoops and a one-shot install are important. Phew, hope this was useful. Hopefully I didn't get things wrong in my depiction above. I think my ideal situation would be for something like wxc to be shipped by default with wxWidgets and for a bunch of exotic languages to use the same layer. If you can make *that* happen by coordinating with various language teams like wxOCaml and with the wxWidgets folks, that'd be super. But it's a sort of long-term thing… (and may get bogged down by people hating the fact that wxc is handwritten when it can so clearly be autogenerated, but then nobody doing anything about it so it just gets stuck). So maybe the right thing to work on there is autogenerated wxc ;-) Eric On 31 May 2013 16:31, harry <vol...@ho...> wrote: > Eric Kow <eric.kow@...> writes: > >> Is the issue something related to the wxdirect executable not being >> available in the sandbox environment? > > Yes - executables built in cabal-dev aren't on the path (which is different > for each sandbox). If wxdirect only built an executable, I could install it > outside of the sandboxes, and it would be available in the path for later use. > > A similar issue arises with wxc - what exactly is it building, and why is an > environment variable needed to find it later? Is it creating a Haskell > library, or just creating come C files for use by wxcore? > > > ------------------------------------------------------------------------------ > 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. > http://p.sf.net/sfu/appdyn_d2d_ap2 > _______________________________________________ > wxhaskell-devel mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel -- Eric Kow <http://erickow.com> |
From: harry <vol...@ho...> - 2013-06-01 18:29:33
|
Eric Kow <eric.kow@...> writes: > May I ask which environment variables in particular you're referring to? All of them, particularly those used to find the location of wxc. cabal-dev installs all dependencies blindly, and doesn't know to set environment variables. > (B) [an aspiring wxHaskell hacker] modify wxcore's Setup.hs to use > wxdirect as a library of some sort. There's a bit of a complication > here in that we're actually faking the dependency on wxdirect: we're > claiming that wxcore depends on wxdirect when the case is more that > the Setup.hs script used by wxcore uses wxdirect. Removing this fake dependency would certainly help (also from wxc and wxcore), because it messes up cabal-dev. > - wxc (the C interface) If I've understood you correctly, wxc doesn't install any Haskell libraries. In which case, could it just create an executable that knows how to generate the C wrapper? wxcore could then run it during setup, and finding it wouldn't be a problem - cabal's bin directory is already on the path. This might also make things easier for users of other languages wanting to share wxc, as only template maniacs expect programs to do their work at compile time :-) My "vision", which may be fatally flawed for not understanding C, C++, WxWidgets, or the WxHaskell build process, is: - cabal install wx-buildtools will install wxdirect (is this really needed as a standalone executable?), and wxc, a program which knows how to create the C wrappers. It will not install any libraries. - cabal install wxcore will run wxc to create the C wrappers, and put them wherever it wants. It will not declare a dependency on wx-buildtools. - cabal install wx at it exist now. |
From: Eric K. <eri...@gm...> - 2013-06-01 20:30:06
|
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 inconvenient/difficult? 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> |
From: Howard B. G. <how...@ya...> - 2013-06-01 21:25:35
|
On 06/01/2013 01:34 PM, Eric Kow wrote: > 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? While you are thinking about this, I hope you will also expand your discussion to the Haskell Platform use case: what would it take to develop a binary add-on that would install wxhaskell on top of a binary HP installation? Extra credit for doing this on Linux, Windows and OS X. In the earlier discussion you mentioned wxc and how it was hand generated. I wonder if the swig tool could be adapted to work with Haskell. This has been discussed for many years. Recently there was a GSoC project to make swig generate a C interface from C++. If this addition to swig is usable, it may be worth trying it to autogenerate wxc or a major part of it. While I use Linux at home and am comfortable building software from source, I think it would be a big win for the Haskell community to have wxhaskell (and gtk2hs) binary packages that run on Windows and OS X since these platforms are used more. Howard |
From: harry <vol...@ho...> - 2013-06-02 06:57:17
|
Eric Kow <eric.kow@...> writes: > 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 inconvenient/difficult? The problem is that cabal-dev tries to install all the dependencies automatically. So if I have a dependency on wx, cabal-dev goes all the way back to wxdirect and tries to install it. This succeeds, but is useless, because the executable won't be found later. It then installs wxc, which I think will succeed if wxdirect has already been installed outside of the sandbox, and can therefore be found on the path. The next hurdle is wxcore, which expects to find various bits of wxc in places that it should really be keeping its nose out of. I suspect that if everything has been set up correctly outsides of the sandbox, this too will succeed by following the environment variables (as long as there aren't any spaces on the path), but I can't actually test this hypothesis because I've upgraded my HP, and wxc/ore won't compile on GHC 7.6. |
From: Eric K. <eri...@gm...> - 2013-06-02 07:03:33
|
On 2 Jun 2013, at 07:56, harry wrote: > The next hurdle is wxcore, which expects to find various bits of wxc in > places that it should really be keeping its nose out of. I suspect that if > everything has been set up correctly outsides of the sandbox, this too will > succeed by following the environment variables (as long as there aren't any > spaces on the path), but I can't actually test this hypothesis because I've > upgraded my HP, and wxc/ore won't compile on GHC 7.6. OK, so I think maybe we should pick this back up when the wxHaskell team have had a chance to catch up with GHC 7.6, because I used wxHaskell in a sandbox (albeit on MacOS X), and have reason to believe that having wxdirect be available on the PATH addresses this pain point. If Blair is still interested in wxHaskell jobs, this is another great one that needs help. Thanks, -- Eric Kow <http://erickow.com> |
From: harry <vol...@ho...> - 2013-06-02 07:44:56
|
Referring to the installation instructions, we have the following environment variables: CABAL_DIR: C:\Users\XXX\AppData\Roaming\cabal (Windows XP: C:\Documents and Settings\XXX\Application Data\cabal, or: %APPDATA%\cabal) GHC_VERSION: 7.0.3 (for our convenience) WXC_VERSION: 0.90.0.2 WXWIN: C:\wxWidgets-2.9.3 WXCFG: gcc_dll\mswu PATH: (add these) %WXWIN%\lib\gcc_dll;%WXWIN%;%CABAL_DIR%\wxc-%WXC_VERSION%\%GHC_VERSION% It may be worth considering how all these are used. In particular, are GHC_VERSION, WXC_VERSION, WXWIN and CABAL_DIR only used for setting the path? |
From: Eric K. <eri...@gm...> - 2013-06-02 08:03:28
|
On 2 Jun 2013, at 08:44, harry wrote: > Referring to the installation instructions, we have the following > environment variables: > > CABAL_DIR: C:\Users\XXX\AppData\Roaming\cabal (Windows XP: C:\Documents > and Settings\XXX\Application Data\cabal, or: %APPDATA%\cabal) > GHC_VERSION: 7.0.3 (for our convenience) > WXC_VERSION: 0.90.0.2 > WXWIN: C:\wxWidgets-2.9.3 > WXCFG: gcc_dll\mswu > PATH: (add these) > %WXWIN%\lib\gcc_dll;%WXWIN%;%CABAL_DIR%\wxc-%WXC_VERSION%\%GHC_VERSION% > > It may be worth considering how all these are used. In particular, are > GHC_VERSION, WXC_VERSION, WXWIN and CABAL_DIR only used for setting the path? I think that these indeed are only used for convenience, so we're down to three environment variables: • WXWIN (used by wxc on compile time • WXCFG: (used by wxc on compile time) • PATH: (add these) (needed on runtime so we can find wxWidgets and wxC respectively) So by rights, as far as building wxHaskell and wxHaskell apps is concerned (sandbox or no), we need “only” really set the WXWIN and WXCFG environment variables. I forget what exactly for, partly to grab the complicated set of compiler flags needed to import and link against the wxWidgets libraries. -- Eric Kow <http://erickow.com> |
From: harry <vol...@ho...> - 2013-06-02 09:41:40
|
Eric Kow <eric.kow@...> writes: > > PATH: (add these) > > %WXWIN%\lib\gcc_dll;%WXWIN%;%CABAL_DIR%\wxc-%WXC_VERSION%\%GHC_VERSION% > So by rights, as far as building wxHaskell and wxHaskell apps is concerned (sandbox or no), we need > “only” really set the WXWIN and WXCFG environment variables. I forget what exactly for, partly to > grab the complicated set of compiler flags needed to import and link against the wxWidgets libraries. OK, so the last component which gets added to the path: %CABAL_DIR%\wxc-%WXC_VERSION%\%GHC_VERSION% That looks like something which really shouldn't be there, what exactly is it used for? Also, is WXWIN used during the build process, as well as when updating the path? |