Hi Brian, I've confirmed that your procedure works for me, too.
I've merged your code into a local copy of the latest Darcs repo, but there's a problem I want to track down before releasing to the Darcs repo. The issue is that I'm seeing exceptions from the Debug build variants (Release is fine). While everything works if I click the 'Ignore Exception' option, this really ought to be fixed. I'm not sure if it's an MSys gcc issue, as this is the first time I've used gcc to build wxc, which is what, in effect, I think Cabal is doing - it doesn't happen for the same code under VS2008. There are a couple of things to consider as they have wider impact - I wanted to put them before the group for consensus before committing code: * The changes as presently implemented remove OpenGL support (and StyledTextControl, I think). While it can be argued that these belong in separate packages (e.g. wx-gl and wx-stc), this only really works for code which compiles to a separate DLL (I think this can be true of everything in the contrib directory). * In this case, wxc is basically subsumed into wxcore as they are built together. On reflection, I think that pulling wxc into wxcore is a good idea, and has benefits compared to the alternative we have been considering (which is to spin wxc off into a separate project). The reason for liking this approach is that Windows developers have been consistently complaining that cabal libraries which depend on external C libraries usually don't work on Windows (I've seen this issue a number of times myself). While I am in complete agreement with the view that it's up to Windows developers to fix the problem, this offers us a way to simply avoid the problem for wxHaskell. Pulling wxc into wxcore makes life very much simpler for all new wxHaskell developers, and I think that lowering the entry barrier is important. It may also help in justifying wxHaskell as a candidate for the Haskell Platform. One other thing to consider - the wxc build system has always been pretty fragile, mainly because of the support for Visual Studio, which complicates everything. Brian's approach lets us get rid of the wxc build system completely, since cabal does the heavy lifting. I'm not really comfortable with removing support for stc, OpenGL and some of the other features - I suspect the right approach is to get the Windows build working using multiple DLLs. At this point, wxCore can depend on the 'standard' set of DLLs, and packages can be added for the optional features (these obviously dependent on having said features available in your wxWidgets installation. One good option may be to commit the code 'as-is' to enable simple cabal install of wxHaskell, and work on putting back the features we have (temporarily) lost. I'd prefer a consensus on what we should do, and will check-in or hold off on code commit as people believe best. I'll give it at least a week before committing to Darcs, for comment (should also give me time to fix the exceptions I'm seeing). Regards Jeremy On Thu, 05 Nov 2009 13:48 -0600, "Brian Lewis" <br...@lorf.org> wrote: > Jeremy, thanks very much for writing back. That helped a lot. > > Here's a procedure that seems to work: > > Install > MinGW 5.1.6 > [x] g++ compiler > [x] MinGW Make > MSYS-1.0.11 > wxMSW-2.8.10 > wx-config Windows port > > In MSYS > cd /c/wxWidgets-2.8.10/build/msw > mingw32-make -f makefile.gcc BUILD=release MONOLITHIC=1 SHARED=1 > UNICODE=1 > > cd ~/wxcore > WXWIN=/c/wxWidgets-2.8.10 WXCFG=gcc_dll/mswu cabal install > > or just > WXWIN=/c/wxWidgets-2.8.10 WXCFG=gcc_dll/mswu cabal install wxcore > once the new stuff is on Hackage. > > Can someone verify that it works? This seems tolerable to me. -- Jeremy O'Donoghue jeremy.odonog...@gmail.com ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
