|
From: Eric K. <eri...@gm...> - 2012-01-05 22:15:21
|
On 5 Jan 2012, at 18:14, Jeremy O'Donoghue wrote: > I am not so keen on this approach. It seems like ever since I have had anything to do with wxHaskell, far more time has been spent on build system issues than on Haskell code or getting new wxWidgets components wrapped. Yup. Churn churn churn. > Don't forget that we started with an autotools-based build system which never really worked properly for Windows. This meant that the bar for becoming a wxHaskell developer was unreasonably high. Well, hang on. Believe me, I am so not doing build system advocacy here. There will be no discussion on the technical merits of one system over another coming from me. All I was talking about is the social calculation: would wxHaskell benefit from a wxc that is maintained outside the Haskell community? Does such a community even exist in the first place, or is a pipe dream? I imagine it *won't* be wxPython/wxRuby etc as they have their own mechanism for getting their bindings. But it might be handy for other small languages, eg. Mercury? Even if such other bindings exist that would use a wxc, would it still be worthwhile, or would the coordination overhead bog us down (being able to just change wxc do what we want makes us pretty nimble). If the social calculation points to "kick wxc out", then the kicked-out wxc should be language-agnostic (well, beyond C and C++ of course). That's all I'm saying. Eric PS: Hmm, I don't think we were using autotools so much as a hand-written Makefile and configure script with a bunch of shell scripts that nobody really understood. Also, I'm not suggesting autotools specifically; if anything, Bakefile instead since it's the same as what wxWidgets use. -- Eric Kow <http://erickow.com> |