On 4 Jan 2012, at 16:59, Dave Tapley wrote: > I do like the idea that wxc is a separate project, upon which wxHaskell > depends, however.. > When configuring wxcore I use wxc's package info, and so require wxc to be > installed by cabal, and I assume it is the intention of the wxC project to be > language independent?
I think that would help. One hope is that if we had a separate project that tried harder to be language agnostic, and which had none of the trappings of a Haskell project, we might be able to get more help from the wxWidgets team. Make it look like any other project written in C, the basic autotools (or more likely Bakefile as wxWidgets use it), the pkgconfig stuff, etc. Then you can imagine wxc getting into your favourite package manager, like Homebrew. > However as I note there it does make wxc dependent on gcc, and now I'm > thinking that the perhaps it's better to move to the language independent wxC > approach (i.e. away from cabal), and use a make system which does 'real' C++ > dependency tracking. Yup. I'd suggest using whatever wxWidgets use. Note also that the wxWidgets people have in the past brought up Swig and the idea of abusing doxygen to generate the wxC layer. -- Eric Kow <http://erickow.com>
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel