From: Dave T. <dav...@gm...> - 2012-01-10 17:02:12
|
On 9 January 2012 22:19, Jeremy O'Donoghue <jer...@gm...>wrote: > 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 > Yikes, these flags are very (imho) counter-intuitive. Referencing a thread I have going: https://groups.google.com/d/msg/wx-dev/4PuKS-xQX3k/JYd4ydh6v-IJ Vadim states that: "DEBUG_FLAG is correctly set to 1 indicating that debug code is not disabled (which is the default)". So I'm substituting "not disable" with "enabled" and reading it as: a release build with debugging enabled, or as you put it: This means I keep the asserts, which seemed like an appropriate > configuration for wxHaskell development. > What I'm not sure about here is whether the "BUILD" flag is superfluous under any GCC build, or just non-Windows GCC builds. A question which I'm asking about here: https://groups.google.com/d/msg/wx-dev/4PuKS-xQX3k/nfUuz_cg-HUJ If the answer to my question there is "under Windows using MSVC", and if we accept that wxHaskell isn't going to support an MSVC build of wxWidgets (which I get the impression is the case); then I suppose that wxC can be completely agnostic to all the (non-libs) wxWidgets build type information (namely: release/debug, debugging flag on/off). Thoughts? > >> >> 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. > Hazaa, I'm going to say it again: *wxHaskell doesn't support an MSVC build of wxWidgets* Is that the sort of message we can put out? > >> 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 :-) > I did actually miss another 'pro' here: I think it's fair to say that wx-config-win is more 'complete' than Eric's Haskell implementation, insomuch as all that's required to fix the "wx-config roadblock" is (I think) changing this line as per Vadim's suggestion : http://code.google.com/p/wx-config-win/source/browse/trunk/wx-config-win.cpp#952 > > >> >> 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. > I don't know either, needs more input I think :( > > Best regards > Jeremy > |