Hi all,
Sorry I've been a little quiet the last week or two, rest assured I have
lurking all along.
On 22 January 2012 00:37, Jeremy O'Donoghue <jeremy.odonog...@gmail.com>wrote:
> I now have wxC building on Windows. Details below and patches attached.
>
Excellent!
I'll take a look.
>
> Jeremy
>
> On 18 January 2012 23:34, Jeremy O'Donoghue
> <jeremy.odonog...@gmail.com>wrote:
>
>> On 17 January 2012 22:40, Jeremy O'Donoghue
>> <jeremy.odonog...@gmail.com>wrote:
>>
>>> On 17 January 2012 21:38, Jeremy O'Donoghue
>>> <jeremy.odonog...@gmail.com>wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have collected together all of the people who I know are making the
>>>> effort to build Dave's latest code on different platforms. I'd also like to
>>>> introduce Andrej, who is testing wxC in the context of D (so could we go
>>>> easy on the Zygohistomorphic Premorphisms and other deep Haskell-ism in
>>>> this thread :-)
>>>>
>>>> I'd suggest that we try to pull together all of the experiences into a
>>>> single thread - makes it easier for people to keep up.
>>>>
>>>> For the moment, I'd like to bring up my experience with wxC on Windows:
>>>>
>>>> First, you need at least a patch to wx-config-win32 which sorts out
>>>> library names (msys libraries are incorrectly named due to a 2.8/2.9
>>>> change)
>>>>
>>>> At line 948 of wx-config-win.cpp, you need:
>>>> if (cfg["BUILD"] == “debug” && cfg["DEBUG_FLAG"] == “default”)
>>>> po["WXDEBUGFLAG"] = “”;
>>>>
>>>> if (cfg["DEBUG_FLAG"] == “1″)
>>>> po["WXDEBUGFLAG"] = “”;
>>>>
>>>>
>>>> Second, in wxc/Setup.hs you need to change line 82 (just after output
>>>> readProcess “wx-config” ["--libs", "std,gl,stc,xrc,richtext,aui,media",
>>>> "--cppflags"] “”
>>>>
>>>> This is needed because wx-config-win does not support the new ‘all’
>>>> flag, and I haven’t had time to fix wx-config-win properly.
>>>>
>>>> Third, the library then builds for me, but fails to link (link errors
>>>> in StyledTextCtrl). I hope to work out why tonight or tomorrow.
>>>>
>>>>
>>>>
>>>>
>>> I've worked out why, but haven't fixed it.
>>>
>>> wx-config-win doesn't know about some of the new libraries, and is
>>> giving incorrect results in other cases. I don't have time to fix this
>>> tonight, but:
>>>
>>> C:\usr\local\src\haskell\wxhaskell-dev\wxhaskell-2.9\wxc>wx-config
>>> --libs base,gl,xrc,richtext,aui,media returns
>>> -mthreads -LD:\Builds\wxWidgets-2.9.3\lib\gcc_dll -lwxmsw29u_richtext
>>> -lwxmsw29u_gl -lopengl32 -lglu32 -lwxmsw29u_media -lwxbase29u -lwxtiff
>>> -lwxjpeg -lwxpng -lwxzlib -lwxregexu -lwxexpat -lkernel32 -luser32
>>> -lgdi32 -lcomdlg32 -lwxregexu -lwinspool -lwinmm -lshell32 -lcomctl32
>>> -lole32
>>> -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32
>>>
>>> C:\usr\local\src\haskell\wxhaskell-dev\wxhaskell-2.9\wxc>wx-config
>>> --libs returns
>>> -mthreads -LD:\Builds\wxWidgets-2.9.3\lib\gcc_dll -lwxmsw29u_html
>>> -lwxmsw29u_adv
>>> -lwxmsw29u_core -lwxbase29u_xml -lwxbase29u_net
>>> -lwxbase29u -lwxtiff -lwxjpeg -lwxpng -lwxzlib -lwxregexu -lwxexpat
>>> -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lw xregexu -lwinspool -lwinmm
>>> -lshell32 -lcomctl32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32
>>> -lwsock32
>>>
>>> Missing base libraries in red.
>>>
>>> I'll try to fix this tomorrow.
>>>
>>>
>>
> I have managed to make wx-config-win work, at least for my configuration.
> There is a known bug which I lack the will to fix right now - the command
> line parser in wx-config-win is very rudimentary and thinks that wx-config
> --libs all --cppflags is looking for the additional library --cppflags.
>
> The work-around is to call wx-config --cppflags --libs all - I have
> changed wxc\Setup.hs to call wx-config this way.
>
> Changes to wx-config-win are quite numerous. The most notable is that the
> Unix wx-config has the set of libraries available (e.g. for "all")
> hard-coded into it (when wx-config.in is turned into wx-config by
> configure). On Windows this is not possible, so I have written a function
> which goes to the library directory of the selected wxWidgets install and
> enumerates all of the wx-related libraries. This is a bit fragile really,
> since it assumes that future wxWidgets libraries follow the current naming
> convention, but it works for now.
>
> I don't have access to the wx-config-win svn repo, so the updated file is
> attached. Oh, and it also builds under VS2010 now (I wanted a decent
> debugger!).
>
> A couple of minor patches were needed to wxc to make it build. These are:
>
> - Reversed the order of libraries, to correctly permit static linking
> (because MinGW GCC actually statically links the implibs).
> - Don't specify wxWidgets version for Windows (wx-config-win doesn't
> support). We do show the detected version, however.
> - Work-around for the wx-config-win --cppflags bug noted above.
> - Add the -Wl,enable-auto-import link flag on Windows, which gets rid
> of a lot of spurious link warnings.
> - Made wxc.a and wxc.dll build in the dist\build directory, so install
> succeeds.
> - Added undef cases for wxAUI event wrappers
>
>
> I am now failing to build wxcore. This is faling to find the wxc header
> files on Windows (it is looking for them in ./include/wxc). I notice that
> Dave has already marked the wxcInstallDir function as dubious, so I'll
> start looking there when it isn't past midnight (a bad time to start
> anything, IME).
>
Mmm, I'm sorry about that.
I actually went for this solution because I'm using cabal-dev to work on
wxHaskell (so I can keep the hackage wxHaskell in my system cabal pkg
conf): I needed a way to find the wxC headers (which obviously should be
part of the wxC package) during the wxcore configure (because wxdirect
(called by wxcore) needs them to generate some Haskell source (the FFI
bindings)).
Whilst I did mark wxcInstallDir as dubious, I do quite like the idea of
having cabal work out which version of wxC it is using to satisfy wxcore's
dependency, and then linking against exactly that version's header files.
The only alternatives I can think of are:
1. Enforce that wxC is installed as a system or user shared library and
find/version it up as we would any other external library (this would be
required if we stopped using cabal).
2. Provide some other (auto-guesswork-or-specify-on-command-line) mechanism
to tell wxcore: "can you configure yourself with the wxC headers here, and
link against this shared library".
Dave,
> NB: Andrej, the contents of this mail should be enough for you to start
> working with wxD on Windows, but please note that I have not tested wxc.dll
> (which is generated in wxc/dist/build, BTW) as I need wxcore built before I
> can try to run any of our test cases.
>
> Regards
> Jeremy
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> wxhaskell-devel mailing list
> wxhaskell-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>
>
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
