On 9 January 2012 22:19, Jeremy O'Donoghue <jeremy.odonog...@gmail.com>wrote:
> On 9 January 2012 18:09, Dave Tapley <dave.a.tap...@gmail.com> wrote:
>
>> On 9 January 2012 17:04, Jeremy O'Donoghue <jeremy.odonog...@gmail.com>wrote:
>>
>>> On 6 January 2012 16:02, Dave Tapley <dave.a.tap...@gmail.com> wrote:
>>>
>>>> 2012/1/6 shelarcy <shela...@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
>
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
