Re: [wxhaskell-devel] The future of wxC
On 16 January 2012 00:46, Eric Kow eric@gmail.com wrote: I was going to post on your blog, but you beat me to mentioning it. So better hear it from me, you should totally use GitHub for wxC. Plus it would be a chance to work with darcs-bridge maybe. 1. Eric will probably kill me for saying this, but I think GitHub is probably the right place, possibly keeping Sourceforge as the project website and distribution point (I personally don't much like git, but it has mindshare, and probably makes more sense than Darcs for a non-Haskell project - plus my experience with patch-tag and darcsden has been that 'getting going' on a Windows machine is far from trivial). I could be persuaded to change my mind on this one, but probably only if one of the Darcs hosts can get the experience 'right' on Windows clients. 2. Keep the Cabal-based build system to start with, until there is clear evidence of non-Haskell contributions. 1. If wxC turns out to have legs, the main areas to attack should be: 1. Move to bakefile based build. 2. Automated generation of the binding. If I may weight in.. I like the idea of moving wxC to a separate project, to at least open it up to other communities, and I'd be happy to have it on GitHub, if that's the consensus. What ever decision we make, do we want to hold off the move on to code.haskell.org until we've made a decision? Actually, it might be easier to get moved across in our current state, and then move out wxC afterwards? R.e. Point 1.2. In the list above, I've been keeping half an eye on this -cafe thread, which seems to be getting more attention than I had anticipated: http://www.mail-archive.com/haskell-cafe@haskell.org/msg96678.html I may be getting ahead of myself.. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ 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
Re: [wxhaskell-devel] The 'making wxC build on all platforms thread
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.comwrote: 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.comwrote: On 17 January 2012 22:40, Jeremy O'Donoghue jeremy.odonog...@gmail.comwrote: On 17 January 2012 21:38, Jeremy O'Donoghue jeremy.odonog...@gmail.comwrote: 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\wxcwx-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\wxcwx-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
Re: [wxhaskell-devel] The future of wxC
On 25 January 2012 15:19, Dave Tapley duked...@gmail.com wrote: On 16 January 2012 00:46, Eric Kow eric@gmail.com wrote: I was going to post on your blog, but you beat me to mentioning it. So better hear it from me, you should totally use GitHub for wxC. Plus it would be a chance to work with darcs-bridge maybe. 1. Eric will probably kill me for saying this, but I think GitHub is probably the right place, possibly keeping Sourceforge as the project website and distribution point (I personally don't much like git, but it has mindshare, and probably makes more sense than Darcs for a non-Haskell project - plus my experience with patch-tag and darcsden has been that 'getting going' on a Windows machine is far from trivial). I could be persuaded to change my mind on this one, but probably only if one of the Darcs hosts can get the experience 'right' on Windows clients. 2. Keep the Cabal-based build system to start with, until there is clear evidence of non-Haskell contributions. 1. If wxC turns out to have legs, the main areas to attack should be: 1. Move to bakefile based build. 2. Automated generation of the binding. If I may weight in.. I like the idea of moving wxC to a separate project, to at least open it up to other communities, and I'd be happy to have it on GitHub, if that's the consensus. What ever decision we make, do we want to hold off the move on to code.haskell.org until we've made a decision? Actually, it might be easier to get moved across in our current state, and then move out wxC afterwards? I tend to favour moving to code.haskell.org first so that it remains easy for Haskellers to work on wxHaskell using only Cabal. I have been thinking along the lines of the cabal version of wxC becoming a stub which contains pre-compiled wxC libraries and headers and installs them for you. I think it's important that 'cabal install wx' continues to work for Haskell users. For that reasson, I'd rather move everything to c.h.o ASAP. R.e. Point 1.2. In the list above, I've been keeping half an eye on this -cafe thread, which seems to be getting more attention than I had anticipated: http://www.mail-archive.com/haskell-cafe@haskell.org/msg96678.html I may be getting ahead of myself.. Me too :-) However, I also generated Doxygen XML output for wxWidgets (which the wxWidgets people seem to favour), and it looks quite nice. Here's a sample - it's the XML generated for the start of class wxPropertyGrid and the method virtual void wxPropertyGrid::DoShowPropertyError(wxPGProperty *property, const wxString amp;msg); compounddef id=classwx_property_grid kind=class prot=public compoundnamewxPropertyGrid/compoundname basecompoundref refid=classwx_control prot=public virt=non-virtualwxControl/basecompoundref basecompoundref refid=classwx_property_grid_interface prot=public virt=non-virtualwxPropertyGridInterface/basecompoundref includes local=nowx/propgrid/propgrid.h/includes sectiondef kind=user-defined headerwxPropertyGrid customization/header descriptionparaReimplement these member functions in derived class for better control over ref refid=classwx_property_grid kindref=compoundwxPropertyGrid/ref behaviour. /para/description memberdef kind=function id=classwx_property_grid_1a6eff1187beba43109be7a12194b0bf2b prot=public static=no const=no explicit=no inline=no virt=virtual typevoid/type definitionvirtual void wxPropertyGrid::DoShowPropertyError/definition argsstring(wxPGProperty *property, const wxString amp;msg)/argsstring nameDoShowPropertyError/name param typeref refid=classwx_p_g_property kindref=compoundwxPGProperty/ref */type declnameproperty/declname /param param typeconst ref refid=classwx_string kindref=compoundwxString/ref amp;/type declnamemsg/declname /param briefdescription paraOverride in derived class to display error messages in custom manner (these message usually only result from validation failure). /para /briefdescription detaileddescription parasimplesect kind=remarkparaIf you implement this, then you also need to implement ref refid=classwx_property_grid_1af170d02811ab8eed906963de693b79aa kindref=memberDoHidePropertyError()/ref - possibly to do nothing, if error does not need hiding (e.g. it was logged or shown in a message box)./para/simplesect simplesect kind=seepararef refid=classwx_property_grid_1af170d02811ab8eed906963de693b79aa kindref=memberDoHidePropertyError()/ref /para/simplesect /para/detaileddescription inbodydescription /inbodydescription location file=D:/Builds/wxWidgets-2.9.3/interface/wx/propgrid/propgrid.h line=1108/ /memberdef Notice that all of the documentation is retained (which would be very nice for documenting wxcore), and that function
Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell
I did some more tests and the 32-bit version is not compiling. The problem is that the 32-bit flags (-m32) are not passed to ld when linking. That in turn is caused by the following: But on hitting that line the following error is spat out: /usr/bin/ld: cannot open output file dist/build/libwxc.so.0.13.1: No such file or directory I checked all my permissions and couldn't see anything wrong, I could touch the file. Conveniently I noticed that, if the verbosity is set high enough, runProgram will call printRawCommandAndArgs: http://hackage.haskell.org/packages/archive/Cabal/latest/doc/html/src/Distribution-Simple-Utils.html#printRawCommandAndArgs The output (i.e. the linker invocation) looks like this: /usr/bin/gcc -fno-stack-protector -shared -Wl,-soname,libwxc.so.0 -o dist/build/libwxc.so.0.13.1 dist/build/src/cpp/apppath.o dist/build/src/cpp/dragimage.o dist/build/src/cpp/eljaccelerator.o [snip-rest-of-.o-files] -L/usr/local/lib -lstdc++ -lwx_baseu-2.9 [snip-rest-of-wx-libs] Now if I cd into the wxcore and paste the command *verbatim* then gcc works and generates libwxc.so.0.13.1 as expected. You can see in Jeremy's code the linkShareLib function contains: cwd - getCurrentDirectory I used this to confirm that the we were in ./wxcore and we are, even making the path for -o absolute didn't sovle the issue. I ended up replacing runProgram line with this, less satisfactory line: system $ (unwords ([show . locationPath . programLocation $ gcc] ++ opts' ++ objs' ++ lib_dirs' ++ libs')) Which works, but still doesn't explain why runProgram doesn't. Any suggestions? The workaround is missing the default arguments. It works again if I change it to: args = opts' ++ objs' ++ lib_dirs' ++ libs' system $ (unwords ([programPath gcc] ++ programDefaultArgs gcc ++ args ++ programOverrideArgs gcc )) Incidentally I also tried the runProgram version, which gave me a similar error: ld: unknown option: -o dist/build/libwxc.dylib I traced the problem down to the rawSystem call, i.e. in ghci: rawSystem /usr/bin/gcc [-o test, dist/build/cpp/apppath.o] gives the same error. I guess gcc/ld does not handle raw strings well??? -- 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
