Menu
▾
▴
wxhaskell-devel
|
From: Brian L. <br...@lo...> - 2009-08-12 22:13:49
|
Hi, I did some work lately on the wxHaskell build process because I was unhappy it wouldn't install via cabal without messing with the global package conf. The repositories I made are here: http://github.com/bsl/wxdirect/tree/master http://github.com/bsl/wxcore/tree/master wxdirect is just lightly modified stuff from the wxHaskell darcs repo. I did some minor cleanup and added an empty library module Application.Wxdirect so it's easier to depend on. wxcore is wxcore and wxc combined. I did away with 'configure' and 'makefile', so now it is just a build-type: Custom package. It builds and installs OK via cabal for me in Linux, and the demo programs in samples/wx work for me, but I'm sure it still has problems, and may not build on Mac OS X or Windows. Please take a look and let me know what's wrong and/or add to the Setup.hs so it works on your platform. It would be cool if all the wxHaskell packages were just more normal packages on HDB. Here are some other issues I was thinking about: To get *.cpp to compile, I had to add a few wxString::FromAscii calls to wxStringify some char*s. I think this is due to some effort in wxGTK to support unicode. My changes made the types match up and stuff, but I felt really unsure about whether it was the correct thing to do. It feels as if maybe *.cpp thinks the data coming from a Haskell String is ASCII, which I think would be wrong. I also get some function deprecation warnings during the build. I don't know how much that is hurting stuff, but it would probably be good to fix. It'd probably be good to get the Haskell sources as -Wall and hlint clean as is reasonable, and check *.cpp with -W -Wall, etc. |
|
From: Eric Y. K. <eri...@gm...> - 2009-08-13 21:59:49
|
On Wed, Aug 12, 2009 at 17:14:08 -0500, Brian Lewis wrote: > Please take a look and let me know what's wrong and/or add to the > Setup.hs so it works on your platform. It would be cool if all the > wxHaskell packages were just more normal packages on HDB. First: wxcore doesn't compile against the default wxWidgets on MacOS X, which is fine because I've gotten used to building my own wxWidgets. Second: the old wxHaskell had a convention where if a wx-config lives in /usr/local/wxhaskell/bin that we would use it. This would make it a bit more straightforward to cabal install wxcore, i.e. without having to do something like PATH=/usr/local/wxhaskell/bin:$PATH cabal install wxcore. Can you think of a good/simple mechanism to let people use their own wxWidgets?? Third: I'm getting linker errors when I try to build something that uses wxHaskell... I think this may be due to the second point. It sounds like we'd need to pass some information to the package description that we write out... Thanks! -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9 |
|
From: Brian L. <br...@lo...> - 2009-08-13 22:21:35
|
On Thursday, 13.08.09 at 22:59, Eric Y. Kow wrote: > First: wxcore doesn't compile against the default wxWidgets on MacOS > X, which is fine because I've gotten used to building my own > wxWidgets. I don't think I have a mac I can work on. Please send me the errors and/or investigate? > Second: the old wxHaskell had a convention where if a wx-config lives in > /usr/local/wxhaskell/bin that we would use it. This would make it a bit > more straightforward to cabal install wxcore, i.e. without having to do > something like PATH=/usr/local/wxhaskell/bin:$PATH cabal install wxcore. > Can you think of a good/simple mechanism to let people use their own > wxWidgets?? I can look into it, but I don't understand. Is it related to installing wxWidgets yourself? Are you saying that /usr/bin/wx-config and /usr/local/wxhaskell/bin/wx-config disagree? That seems bad. |
|
From: Eric K. <eri...@gm...> - 2009-08-14 09:36:57
|
On Thu, Aug 13, 2009 at 17:22:05 -0500, Brian Lewis wrote: > On Thursday, 13.08.09 at 22:59, Eric Y. Kow wrote: > > First: wxcore doesn't compile against the default wxWidgets on MacOS > > X, which is fine because I've gotten used to building my own > > wxWidgets. > > I don't think I have a mac I can work on. Please send me the errors > and/or investigate? I'll send you the errors first. I think it's just that when compiling my software GenI, GHC isn't getting the -L flags it needs to find my wxWidgets (say -L /custom/wxWidgets-2.8/lib). We know what these flags are since we can compile wxcore; we just need to save them to the package description > > Second: the old wxHaskell had a convention where if a wx-config lives in > > /usr/local/wxhaskell/bin that we would use it. This would make it a bit > > more straightforward to cabal install wxcore, i.e. without having to do > > something like PATH=/usr/local/wxhaskell/bin:$PATH cabal install wxcore. > > Can you think of a good/simple mechanism to let people use their own > > wxWidgets?? > > I can look into it, but I don't understand. Is it related to installing > wxWidgets yourself? Are you saying that /usr/bin/wx-config and > /usr/local/wxhaskell/bin/wx-config disagree? That seems bad. It is related to installing wxWidgets myself (*) MacOS X ships with its own wxWidgets, which /usr/bin/wx-config points to. I just need to make sure I'm running the wx-config that goes with my wxWidgets instead. Perhaps a simple solution is just for us to ship docs that remind people to edit their bashrc files and put their wxWidgets bin in the PATH. No silly mechanisms. * A regrettable necessity on Macs for some reason; too bad too, because I was pretty psyched about MacOS X shipping with wxWidgets by default. Actually, for some odd reason I can't get wxHaskell to work with Ubuntu 9.04's wxGTK either and had to install my own as well. -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9 |
|
From: Eric Y. K. <eri...@gm...> - 2009-08-15 20:58:43
Attachments:
wxcore-description
bouncing-balls
|
On Thu, Aug 13, 2009 at 22:59:32 +0100, Eric Y. Kow wrote: > Third: I'm getting linker errors when I try to build something that > uses wxHaskell... I think this may be due to the second point. It > sounds like we'd need to pass some information to the package > description that we write out... Just an update on this. First, I looked at the ghc-pkg describe output for wxcore and lo!, it was getting the -L and -l flags for my wxWidgets as it should have been (note the extra-library-dirs /usr/local/lib) Second, to simplify this, I tried just building the wxcore sample for BouncingBalls and got the same linker error. Hmmph :-( Oh well, at least we've cut down a couple of variables (cabal, since we're using ghc --make to build BouncingBalls, GenI since we're just using a sampler and wx since we're just using the wxcore sample). -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9 |
|
From: Eric Y. K. <eri...@gm...> - 2009-09-02 16:16:54
|
Hi Brian, On Sat, Aug 15, 2009 at 21:58:20 +0100, Eric Y. Kow wrote: > > Third: I'm getting linker errors when I try to build something that > > uses wxHaskell... I think this may be due to the second point. It > > sounds like we'd need to pass some information to the package > > description that we write out... I just tried doing this again and for some reason, this time it works! I can't figure out what I've done differently (perhaps setting my PATH to point to my version of wxWidgets not just for cabal configure and cabal build, but for cabal install?), but this is very encouraging. If I'm right, it means that thanks to you, we now have a fully Cabalised wxHaskell that installs in the user directory. That's pretty exciting for anybody using wxHaskell in their applications because it means we can tell people: 1. install wxWidgets 2. if it's a custom wxWidgets, set your PATH 3. cabal install my-application which is a big improvement! -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9 |
Thanks for helping keep SourceForge clean.
X