Re: [wxhaskell-devel] Happy New Year, wxHaskellers

[Dave T. <dav...@gm...>]

On 2 January 2012 09:22, Eric Kow <eri...@gm...> wrote:

>
> On 2 Jan 2012, at 08:48, Jeremy O'Donoghue wrote:
>
> >       • wxC is built as a shared library. This means that wxHaskell
> works in GHCi again, which has been one of the most requested bugfixes over
> the past 18 months or so.
>
> Sweet!
>
> I've made you and Dave admins to the wxC SF project, just in case you felt
> it would help to dissociate it from wxHaskell (thereby attracting people
> from other language bindings, or people who just want to write wxWidgets
> GUIs in C).  The idea could be that wxC would be developed to track
> wxWidgets, whereas wxHaskell would be trying to keep up with wxC.  But
> maybe this would just be a big distraction.  Up to you :-)
>

Ah, I saw wxC before and assumed the project was dead.
As such, in my branch wxc lives entirely under within wxHaskell, here:
http://darcsden.com/DukeDave/wxhaskell-dev/browse/wxc

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?
You can see (and I invite you to comment on) my use of wxc's package info
in wxcInstallDir, here:
http://darcsden.com/DukeDave/wxhaskell-dev/browse/wxcore/Setup.hs


>
> Also, I imagine that while this brings us closer to wxHaskell in GHCi, we
> would still need to solve the second start crash?
>
>
> https://sourceforge.net/tracker/?func=detail&aid=1610984&group_id=7the3133&atid=536845<https://sourceforge.net/tracker/?func=detail&aid=1610984&group_id=73133&atid=536845>
>

Well, I just had a look, and that issue seems to have gone away in my
darcsden branch!
I've added a comment to the tracker.


>
> >       • Build system improvements to reduce 'unnecessary' rebuilding of
> source files - again, one for developers.
>
> Yay!
>

Oh, one note here:
At the moment I'm using Jeremy's getModificationTime on src and obj
approach to dependency checking, which he put his hand up to not really
being robust enough:
https://sourceforge.net/mailarchive/message.php?msg_id=28121303

You can see where this turns up under needsCompiling here in my repo:
http://darcsden.com/DukeDave/wxhaskell-dev/browse/wxc/Setup.hs

Now I do actually have a patch sat on my machine which adds better
dependency tracking, I alluded to it here:
http://www.haskell.org/pipermail/cabal-devel/2011-October/007816.html

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.

Dave,


> --
> Eric Kow <http://erickow.com>
>
>
> -----BEGIN PGP SIGNATURE-----
>
> iEYEARECAAYFAk8Bd14ACgkQBUrOwgisBPkGAwCfdZYMF2brAwOH2rM660Bh1pXN
> QHgAn2LdNVkXGIRMGJ0xGAmlDWnQXfej
> =2c1B
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> 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
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>
>