Hi all, Attached are patches which enable me to build and Dave's repo on Windows. I have built and run most of the samples and test cases (including OpenGL, STC and PropertyGrid) I also included Nicholas Tung's patch from a couple of days back to support GHC 7.2.2 by adding some FlexibleInstances pragmas.
The remaining issue on Windows is that GHCi is not working as it should. I will look at this next. On 25 January 2012 15:33, Dave Tapley <duked...@gmail.com> wrote: > On 22 January 2012 00:37, Jeremy O'Donoghue <jeremy.odonog...@gmail.com>wrote: > >> I now have wxC building on Windows. Details below and patches attached. >> > > Excellent! > I'll take a look. > > >> I am now failing to build wxcore. This is faling to find the wxc header >> files on Windows (it is looking for them in ./include/wxc). I notice that >> Dave has already marked the wxcInstallDir function as dubious, so I'll >> start looking there when it isn't past midnight (a bad time to start >> anything, IME). >> > > Mmm, I'm sorry about that. > I actually went for this solution because I'm using cabal-dev to work on > wxHaskell (so I can keep the hackage wxHaskell in my system cabal pkg > conf): I needed a way to find the wxC headers (which obviously should be > part of the wxC package) during the wxcore configure (because wxdirect > (called by wxcore) needs them to generate some Haskell source (the FFI > bindings)). > The solution turned out to be simpler than I expected: the working code for Linux was using System.Directory.Posix, when System.Directory will get you the same thing, but internally select between System.Directory.Posix and System.Directory.Windows. No prizes for guessing which you need on Windows :-) > > Whilst I did mark wxcInstallDir as dubious, I do quite like the idea of > having cabal work out which version of wxC it is using to satisfy wxcore's > dependency, and then linking against exactly that version's header files. > The only alternatives I can think of are: > > 1. Enforce that wxC is installed as a system or user shared library and > find/version it up as we would any other external library (this would be > required if we stopped using cabal). > > 2. Provide some other (auto-guesswork-or-specify-on-command-line) > mechanism to tell wxcore: "can you configure yourself with the wxC headers > here, and link against this shared library". > Actually, after some reflection, I don't think wxcInstallDir is dubious at all. It is, I think, using a documented Cabal API, and it works on all Cabal platforms. One area where we do have an issue is that wxc.dll gets installed somewhere no sane human being would evenr look to find it. I think the solution will be to do a skeleton wxHaskell project Cabal file which pulls all of the dlls from their install directory and copies them to dist/build, or something similar. Regards Jeremy
changes-to-make-wxc-build-for-windows_.dpatch
Description: Binary data
------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
