Re: [wxhaskell-devel] [wxhaskell-users] ANN: wxHaskell 0.13.2

[Jeremy O'D. <jer...@gm...>]

On 9 January 2012 18:09, Dave Tapley <dav...@gm...> wrote:

> On 9 January 2012 17:04, Jeremy O'Donoghue <jer...@gm...>wrote:
>
>> On 6 January 2012 16:02, Dave Tapley <dav...@gm...> wrote:
>>
>>> 2012/1/6 shelarcy <she...@gm...>
>>>
>>
>> Needless to say, I have immediately hit the wx-config roadblock, since I
>> have compiled a release build of wxWidgets 2.9.3, and wx-config-win only
>> knows about debug builds.
>>
>
> Welcome to the party :)
> Just for the sake of clarity, I feel obliged to question your use of the
> words "release" and "debug"; are you aware of the "Debug Build Changes in
> wx3"?
> Here's the news:
> http://wxwidgets.blogspot.com/2009/09/debug-build-changes-in-wx3.html
> (seeing the date of the post made me realise just how far behind we are,
> and also how slow the wxWidgets release cycles are!)
>
>
I wasn't aware of the blog posting, but I did realise that there were
changes in this area - some of this is covered in the install instructions.
Strictly I built with:

BUILD=release
DEBUG_INFO=default
DEBUG_FLAG=1

This means I keep the asserts, which seemed like an appropriate
configuration for wxHaskell development.


>
> That has manifested itself in this known issue with wx-config-win:
> http://code.google.com/p/wx-config-win/issues/detail?id=21
>
> Finally, just out of curiosity: Did you build wxWidgets with VC++ or gcc?
> I dutifully downloaded the free version of Visual C++ 2010 express, loaded
> the wxWidgets 2.9.3 project, built, and ran some sample code. However when
> I tried to use wx-config-win I realised that it required a "build.cfg"
> file, which isn't generated when you build with VC++ (I suppose because
> VC++ manages all the build settings itself, and so doesn't need to export
> anything). Without this one is unable to install wxHaskell.
>

I built with gcc. I have played with VC++ in the past, because the build
'just works' but it was really too painful to sort out the configuration.

>
> I turned to the wiki and discovered this:
> http://www.scribd.com/doc/38034374/20100923-WxHaskell-Setup)
>
> Using it as a guide (note that one can't use wxPack because there are no
> wxPack releases for the development (2.9.x) releases of wxWidgets) I was
> (almost) able to cabal install wxHaskell from my darcsden branch (it failed
> because I didn't --with-OpenGL the wxWidgets configure, and then I ran out
> of time).
>
>
>> I am leaning towards doing something with Eric's wx-config. There are a
>> couple of reasons for this:
>>
>>    - It keeps us in control of our own destiny;
>>    - Haskell is a *much* more pleasant implementation language for a
>>    utility which mainly does text processing than C++.
>>
>> Does the group have an opinion on this? My feeling is that since the last
>> commit to wx-config-win was in 2006, it may be a while before fixes come
>> along, and even then, we will probably need to write the patches.
>>
> Ah, well, yes..
> Firstly the pro-(wx-config-win) items:
> * I contacted the owner of wx-config-win and he made me an owner of the
> Google code project, so we're 'in charge' now.
> * I got a small discussion going on its existence in #wxwidgets on
> freenode. The consensus is that, because /most/ people use Visual Studio
> (in some flavour) to develop with wxWidgets in Windows, there simply wasn't
> the need to maintain wx-config-win. As a result it was never stable enough
> to merit merging in to the wxWidgets code base. By comparison the wx-config
> we know and love on Linux systems (and, I presume, OS X?) is essential and
> so well maintained:
>
> http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/wx-config.in
> (I didn't realise until recently that it is just a shell script, copied in
> to your install dir and symlinked into your PATH).
>

I did know that wx-config is just a shell script. I'm not so surprised that
most wxWidgets developers on Windows use VS. It's a really nce development
environment. I actually think they advertise support for too many build
options when in reality only a few of them get any serious use.

I was actually planning on looking carefully at wx-config while updating
Eric's Haskell wx-config :-)


>
> And now the cons:
> * It is woefully out of date. There are 18 open issues (
> http://code.google.com/p/wx-config-win/issues/list) and who knows how
> many undiscovered bugs.
> * As mentioned, the wxWidgets community doesn't seem desperately fussed
> about its existence, so long as Visual Studio is around
> * It's implementation is in need of an overhaul, as identified by the
> previous owner (http://code.google.com/p/wx-config-win/issues/detail?id=6)
>

I tend to think that you've hit on the problem with this approach. The
wxWidgets community doesn't really care. Therefore we would be left
maintaining a piece of C++ to support what is basically our own need.

>
> So, in summary, I'm not sure.
> My optimist, open-source heart says we should resurrect the wx-win-config
> project.
> My do-it-the-right-way heart says we ditch the existing C++ source and
> replicate the shell script (Windows PowerShell anyone?)
> My everything-is-wonderful-with-Haskell heart says let's just roll our
> own, no one uses wx-config-win anyway, and all it does it find a few
> headers and libs.
>
>

I think a port of wx-config (shell) to Haskell is probably easier than
doing a port into PowerShell (which I've never touched...), but I take your
point about the 'right way'.

I'll nail my colours to the mast and leave things open for debate after
that.

   - My day job is C++. Thus I tend to tolerate doing it for my 'fun'
   projects where it is needed (e.g. wrapping a C++ library), but I kind-of
   prefer to spend my spare time writing Haskell rather than C++ ;-)
   - While the 'community' aspect of having a wxC is superficially
   attractive, I think history is against the idea that it is something the
   world really needs:
      - wxC has been moribund for years. I don't think it's been touched
      for over 5 years. This suggests that there is not so much demand
out there.
      - wxHaskell has struggled for contributons for as long as I remember.
      I basically became involved because I didn't want to see it bit-rot.


What I *do* believe is that there is a real demand in the Haskell community
for a GUI with native look and feel, commercial-friendly licensing and ease
of installation. My preference, therefore, is to move wxHaskell in that
direction as far as possible, and to make the bar for becoming a developer
as low as possible for Haskell developers. Basically, I want to enable the
Haskell ecosystem, and that's why I'm a big fan of cabal install, despite
its limitations as a generalised build system.

Having said my piece, I fully understand why others may have a different
view, and I think if there was I strong indication that other language
communities had a serious interest in using and helping to maintain wxC, I
would be easily persuaded in that direction. What I don't really believe is
in 'if you build it, they will come'.

I'll leave things for a couple of days to let others have their say, and
then follow the community preference.

Best regards
Jeremy