On Tue, Nov 10, 2009 at 12:42:28 +0000, Jeremy O'Donoghue wrote: > 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.
Note that you now have control of the wxc project, with thanks to Pascal, so we still have the power to rethink this. Two axes of re-thinkitude would be (a) having a standard autoconf-based build system for wxc and (b) scrapping wxC and automatically generating it from wxWidgets source. Now that we have Brian's work I guess it'd make sense to forget about (a) and just work on (b) in the long run. > 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. Note that I removed OpenGL support to make wxHaskell build on MacOS X. I was having a really hard time otherwise. I personally think it would make sense for the wxHaskell project to reduce its liabilities in a sense and focus on having things "just work" (rather than trying to do a lot of them). Imagine if wxHaskell had a reputation for being easier to get started with than gtk2hs :-) [borrowing this bit from above] > 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). So I'm not sure I understand this? If it is true, why not go ahead and have them be separate packages? You'd be reducing headaches in installing wxHaskell and the work you do in this will pave the way for future extensions with other fancy widgets. > 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. It's also worth considering that we have some core issues to fix like making wxHaskell more usable within GHCi (this is the multiple starts problem that Conal suffers from), so IMHO, it'd make sense to commit the code as is, focus on those problems and worry about cool features later. Woo! :-) -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ 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
