On 9 January 2012 22:19, Jeremy O'Donoghue <jeremy.odonoghue@gmail.com> wrote:
On 9 January 2012 18:09, Dave Tapley <dave.a.tapley@gmail.com> wrote:
On 9 January 2012 17:04, Jeremy O'Donoghue <jeremy.odonoghue@gmail.com> wrote:
On 6 January 2012 16:02, Dave Tapley <dave.a.tapley@gmail.com> wrote:
2012/1/6 shelarcy <shelarcy@gmail.com> 
 
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