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
Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell
However, keyboard input is not directed to the gui but to the ghci terminal… There used to be an EnableGUI module to fix this (http://www.haskell.org/haskellwiki/WxHaskell/MacOS_X), but that does not seem to work anymore. The window can be closed and restarted from ghci though. However, the window does not actually disappear until ghci is exited. I'm a little confused by this statement? Do you mean: You can close the window, and ghci returns to the prompt, but the actual window manager window remains? If I press the close button (there is no menubar), the window does not actually disappear but it does not react to any (mouse) inputs anymore and the ghci prompt returns. Without keyboard input going to the gui and without a menu bar, the gui is not really useful yet I guess, so I hope this is fixable. Oh, I understand now. I haven't heard of this before, but it sounds like exactly the kind of weirdness I'd expect. Anyone? Hmm, it appears the example I was using was broke. With the HelloWorld sample and using: main = enableGUI start hello the mouse and keyboard input do go to the window under GHCi. So this is great as I now can do everything I could do before in GHC 6.10. If I close the window it does remain visible in an unusable state until you exit ghci. However, control returns to GHCi and I can restart the application (i.e. run main again), re-using the same window. So that is an improvement over before (which crashed ghci when closing the window). -- 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
Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell
On Thu, Jan 12, 2012 at 5:19 PM, Dave Tapley duked...@gmail.com wrote: On 12 January 2012 15:09, Jeremy O'Donoghue jeremy.odonog...@gmail.com wrote: Thank you Kenneth, That's an extremely detailed and complete set of notes. It is very much appreciated. I'd also like to offer my thanks, this is extremely useful to us. You're welcome. Thanks for replying otherwise my post would not even be visible. I guess some copy-past action html-ified it. And here I was thinking attachments would be a problem :) Best regards Jeremy On 12 January 2012 14:52, Frodo Kenny frodoken...@gmail.com wrote: Nice work. I was still on GHC 6.10 to be able to use wxhaskell with ghci. Here are some notes and patches for OS X. I'm running Lion (10.7.2) and getting wxwidgets running actually took the most time. 1) wxwidgets First of all, Haskell and wxwidgets must use the same architecture, i.e. both 32-bit or both 64-bit. This never occurred to me, well spotted. We should check this, so I've created a ticket: https://sourceforge.net/tracker/?func=detailaid=3472972group_id=73133atid=536848 Good idea. The standard build is 64-bit, but wxwidgets includes the QuickTime framework which is only available in 32-bit. It builds and ghc only gives a warning, but ghci will give an error (/System/Library/Frameworks/QuickTime.framework/QuickTime: mach-o, but wrong architecture). To build 32-bit you can use --enable-macosx_arch=i386. It looks like quicktime is only used for PICT support, which is disabled in 64-bit builds anyway, so I made a patch that disables quicktime for both 32 and 64 bit cocoa builds. By further disabling the ppc architecture, we can make a universal 32/64-bit binary with: =remove -arch ppc in configure =remove -framework QuickTime in configure =remove PICT by __LP64__ - __WXOSX_COCOA__ in bitmap.c, fontenum.c, metafile.cpp ./configure --disable-debug --disable-dependency-tracking --with-osx_cocoa --disable-webkit --with-macosx-sdk=/Developer/SDKs/MacOSX10.6.sdk --with-macosx-version-min=10.6 --enable-universal_binary make install Note that on lion with the latest Xcode, 10.6 is the lowest sdk version. I use Homebrew so I attached a formula for it. To install homebrew: /usr/bin/ruby -e $(curl -fsSL https://raw.github.com/gist/323731) Then put wxosx.rb in /usr/local/Library/Formula and run: brew install wxosx I'm not an OS X person, so this doesn't really mean anything to me; is it something which should be on the wiki? I think that would be useful (homebrew is a package manager and the attached formula applies the patches and installs wxwidgets 2.9.3 relatively easy). 2) wxhaskell installing wxc gives: cd wxc cabal install - error wxEVT_WEBKIT_ was not declared… so I disabled webkit in wxwidgets above. -ld: file not found: undefined =change -Wl,undefined to -Wl,-undefined in linkCxxOpts in Setup.hs installing wxcore -* Missing C library: wxc name is wxc.so instead of libwxc.dylib =change for sharedLibName: OSX - lib ++ addExtension basename .dylib in Setup.hs ghc --make HelloWorld.hs Undefined symbols for architecture x86_64: _expEVT_DIALUP_DISCONNECTED I don't know where this is coming from (dialupman is enabled in wxwidgets) so I commented out the DIALUP lines in wxc_glue.h ./HelloWorld - dlopen(dist/build/libwxc.dylib) failed The final problem is that a dylib contains an absolute paths used for linking, and the library is expected to be found at that locations. To set this path we must pass the -install_name argument when linking libwxc.dylib = OSX - [-dynamiclib, -o ++ out_dir / sharedLibName ver basename, -install_name ++ basepath / sharedLibName ver basename, -Wl,-undefined,dynamic_lookup] in linkCxxOpts, thus needing an extra basepath argument this is found by adding =inst_lib_dir = libdir $ absoluteInstallDirs pkg_descr local_bld_info NoCopyDest to myBuildHook and also using an extra argument for linkSharedLib. Thank you very much for the patch, but I have one tiny request: I can't apply wxhaskell-osx.patch because the structure doesn't match the one on my system. Could you record it with darcs and send the patch bundle as an attachment (darcs send -o mypatch.dpatch) http://darcs.net/manual/Darcs_commands.html#SECTION00661000 http://darcs.net/manual/Darcs_commands.html#SECTION00664000 Also, if you record the patches your name will forever be attached to them and you will received the karma you deserve :) Done. The diff was only for the wxc directory, so maybe that was it. But karma is nice... 3) using wxhaskell ghc --make seems to work with the limited testing that I did ghci error:
Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell
Nice work. I was still on GHC 6.10 to be able to use wxhaskell with ghci.
Here are some notes and patches for OS X. I'm running Lion (10.7.2) and
getting wxwidgets running actually took the most time.
1) wxwidgets
First of all, Haskell and wxwidgets must use the same architecture, i.e.
both 32-bit or both 64-bit.
The standard build is 64-bit, but wxwidgets includes the QuickTime
framework which is only available in 32-bit. It builds and ghc only gives a
warning, but ghci will give an error
(/System/Library/Frameworks/QuickTime.framework/QuickTime: mach-o, but
wrong architecture).
To build 32-bit you can use --enable-macosx_arch=i386.
It looks like quicktime is only used for PICT support, which is disabled in
64-bit builds anyway, so I made a patch that disables quicktime for both 32
and 64 bit cocoa builds.
By further disabling the ppc architecture, we can make a universal
32/64-bit binary with:
=remove -arch ppc in configure
=remove -framework QuickTime in configure
=remove PICT by __LP64__ - __WXOSX_COCOA__ in bitmap.c, fontenum.c,
metafile.cpp
./configure --disable-debug --disable-dependency-tracking
--with-osx_cocoa --disable-webkit
--with-macosx-sdk=/Developer/SDKs/MacOSX10.6.sdk
--with-macosx-version-min=10.6 --enable-universal_binary
make install
Note that on lion with the latest Xcode, 10.6 is the lowest sdk version.
I use Homebrew so I attached a formula for it. To install homebrew:
/usr/bin/ruby -e $(curl -fsSL https://raw.github.com/gist/323731)
Then put wxosx.rb in /usr/local/Library/Formula and run:
brew install wxosx
2) wxhaskell
installing wxc gives:
cd wxc
cabal install
- error wxEVT_WEBKIT_ was not declared…
so I disabled webkit in wxwidgets above.
-ld: file not found: undefined
=change -Wl,undefined to -Wl,-undefined in linkCxxOpts in Setup.hs
installing wxcore
-* Missing C library: wxc
name is wxc.so instead of libwxc.dylib
=change for sharedLibName: OSX - lib ++ addExtension basename .dylib
in Setup.hs
ghc --make HelloWorld.hs
Undefined symbols for architecture x86_64:
_expEVT_DIALUP_DISCONNECTED
I don't know where this is coming from (dialupman is enabled in wxwidgets)
so I commented out the DIALUP lines in wxc_glue.h
./HelloWorld
- dlopen(dist/build/libwxc.dylib) failed
The final problem is that a dylib contains an absolute paths used for
linking, and the library is expected to be found at that locations. To set
this path we must pass the -install_name argument when linking
libwxc.dylib
= OSX - [-dynamiclib,
-o ++ out_dir / sharedLibName ver basename,
-install_name ++ basepath / sharedLibName ver
basename,
-Wl,-undefined,dynamic_lookup]
in linkCxxOpts, thus needing an extra basepath argument
this is found by adding
=inst_lib_dir = libdir $ absoluteInstallDirs pkg_descr
local_bld_info NoCopyDest
to myBuildHook and also using an extra argument for linkSharedLib.
3) using wxhaskell
ghc --make seems to work with the limited testing that I did
ghci error: +[NSUndoManager(NSInternal) _endTopLevelGroupings] is only safe
to invoke on the main thread.
ghci creates a new thread for each computation and under os x the gui
apparently must run on the main (first) thread.
This is solved by:
ghci -fno-ghci-sandbox
However, keyboard input is not directed to the gui but to the ghci terminal…
There used to be an EnableGUI module to fix this (
http://www.haskell.org/haskellwiki/WxHaskell/MacOS_X), but that does not
seem to work anymore.
The window can be closed and restarted from ghci though. However, the
window does not actually disappear until ghci is exited.
Does anybody know how this was working/can be fixed?
Hope this is useful.
Regards,
Kenneth
require 'formula'
class Wxosx Formula
url 'http://downloads.sourceforge.net/project/wxwindows/2.9.3/wxWidgets-2.9.3.tar.bz2'
homepage 'http://www.wxwidgets.org'
md5 '6b6003713289ea4d3cd9b49c5db5b721'
# depends_on 'cmake' = :build
def install
system ./configure, --disable-debug, --disable-dependency-tracking,
--prefix=#{prefix}, --with-osx_cocoa, --disable-webkit,
--with-macosx-sdk=/Developer/SDKs/MacOSX10.6.sdk, --with-macosx-version-min=10.6, --enable-universal_binary
# , --enable-macosx_arch=i386
# system cmake . #{std_cmake_parameters}
system make install
end
def patches
# fixes deprecated QuickTime framework
DATA
end
# def test
# # This test will fail and we won't accept that! It's enough to just
# # replace false with the main program this formula installs, but
# # it'd be nice if you were more thorough. Test the test with
# # `brew test wxWidgets`. Remove this comment before submitting
# # your pull request!
# system false
# end
end
__END__
diff --git a/configure b/configure
index 3d5b60d..5fba29d 100755
--- a/configure
+++ b/configure
@@ -19253,7
Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell
Thank you Kenneth, That's an extremely detailed and complete set of notes. It is very much appreciated. Best regards Jeremy On 12 January 2012 14:52, Frodo Kenny frodoken...@gmail.com wrote: Nice work. I was still on GHC 6.10 to be able to use wxhaskell with ghci. Here are some notes and patches for OS X. I'm running Lion (10.7.2) and getting wxwidgets running actually took the most time. 1) wxwidgets First of all, Haskell and wxwidgets must use the same architecture, i.e. both 32-bit or both 64-bit. The standard build is 64-bit, but wxwidgets includes the QuickTime framework which is only available in 32-bit. It builds and ghc only gives a warning, but ghci will give an error (/System/Library/Frameworks/QuickTime.framework/QuickTime: mach-o, but wrong architecture). To build 32-bit you can use --enable-macosx_arch=i386. It looks like quicktime is only used for PICT support, which is disabled in 64-bit builds anyway, so I made a patch that disables quicktime for both 32 and 64 bit cocoa builds. By further disabling the ppc architecture, we can make a universal 32/64-bit binary with: =remove -arch ppc in configure =remove -framework QuickTime in configure =remove PICT by __LP64__ - __WXOSX_COCOA__ in bitmap.c, fontenum.c, metafile.cpp ./configure --disable-debug --disable-dependency-tracking --with-osx_cocoa --disable-webkit --with-macosx-sdk=/Developer/SDKs/MacOSX10.6.sdk --with-macosx-version-min=10.6 --enable-universal_binary make install Note that on lion with the latest Xcode, 10.6 is the lowest sdk version. I use Homebrew so I attached a formula for it. To install homebrew: /usr/bin/ruby -e $(curl -fsSL https://raw.github.com/gist/323731) Then put wxosx.rb in /usr/local/Library/Formula and run: brew install wxosx 2) wxhaskell installing wxc gives: cd wxc cabal install - error wxEVT_WEBKIT_ was not declared… so I disabled webkit in wxwidgets above. -ld: file not found: undefined =change -Wl,undefined to -Wl,-undefined in linkCxxOpts in Setup.hs installing wxcore -* Missing C library: wxc name is wxc.so instead of libwxc.dylib =change for sharedLibName: OSX - lib ++ addExtension basename .dylib in Setup.hs ghc --make HelloWorld.hs Undefined symbols for architecture x86_64: _expEVT_DIALUP_DISCONNECTED I don't know where this is coming from (dialupman is enabled in wxwidgets) so I commented out the DIALUP lines in wxc_glue.h ./HelloWorld - dlopen(dist/build/libwxc.dylib) failed The final problem is that a dylib contains an absolute paths used for linking, and the library is expected to be found at that locations. To set this path we must pass the -install_name argument when linking libwxc.dylib = OSX - [-dynamiclib, -o ++ out_dir / sharedLibName ver basename, -install_name ++ basepath / sharedLibName ver basename, -Wl,-undefined,dynamic_lookup] in linkCxxOpts, thus needing an extra basepath argument this is found by adding =inst_lib_dir = libdir $ absoluteInstallDirs pkg_descr local_bld_info NoCopyDest to myBuildHook and also using an extra argument for linkSharedLib. 3) using wxhaskell ghc --make seems to work with the limited testing that I did ghci error: +[NSUndoManager(NSInternal) _endTopLevelGroupings] is only safe to invoke on the main thread. ghci creates a new thread for each computation and under os x the gui apparently must run on the main (first) thread. This is solved by: ghci -fno-ghci-sandbox However, keyboard input is not directed to the gui but to the ghci terminal… There used to be an EnableGUI module to fix this ( http://www.haskell.org/haskellwiki/WxHaskell/MacOS_X), but that does not seem to work anymore. The window can be closed and restarted from ghci though. However, the window does not actually disappear until ghci is exited. Does anybody know how this was working/can be fixed? Hope this is useful. Regards, Kenneth -- 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 -- 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
Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell
On 12 January 2012 15:09, Jeremy O'Donoghue jeremy.odonog...@gmail.com wrote: Thank you Kenneth, That's an extremely detailed and complete set of notes. It is very much appreciated. I'd also like to offer my thanks, this is extremely useful to us. Best regards Jeremy On 12 January 2012 14:52, Frodo Kenny frodoken...@gmail.com wrote: Nice work. I was still on GHC 6.10 to be able to use wxhaskell with ghci. Here are some notes and patches for OS X. I'm running Lion (10.7.2) and getting wxwidgets running actually took the most time. 1) wxwidgets First of all, Haskell and wxwidgets must use the same architecture, i.e. both 32-bit or both 64-bit. This never occurred to me, well spotted. We should check this, so I've created a ticket: https://sourceforge.net/tracker/?func=detailaid=3472972group_id=73133atid=536848 The standard build is 64-bit, but wxwidgets includes the QuickTime framework which is only available in 32-bit. It builds and ghc only gives a warning, but ghci will give an error (/System/Library/Frameworks/QuickTime.framework/QuickTime: mach-o, but wrong architecture). To build 32-bit you can use --enable-macosx_arch=i386. It looks like quicktime is only used for PICT support, which is disabled in 64-bit builds anyway, so I made a patch that disables quicktime for both 32 and 64 bit cocoa builds. By further disabling the ppc architecture, we can make a universal 32/64-bit binary with: =remove -arch ppc in configure =remove -framework QuickTime in configure =remove PICT by __LP64__ - __WXOSX_COCOA__ in bitmap.c, fontenum.c, metafile.cpp ./configure --disable-debug --disable-dependency-tracking --with-osx_cocoa --disable-webkit --with-macosx-sdk=/Developer/SDKs/MacOSX10.6.sdk --with-macosx-version-min=10.6 --enable-universal_binary make install Note that on lion with the latest Xcode, 10.6 is the lowest sdk version. I use Homebrew so I attached a formula for it. To install homebrew: /usr/bin/ruby -e $(curl -fsSL https://raw.github.com/gist/323731) Then put wxosx.rb in /usr/local/Library/Formula and run: brew install wxosx I'm not an OS X person, so this doesn't really mean anything to me; is it something which should be on the wiki? 2) wxhaskell installing wxc gives: cd wxc cabal install - error wxEVT_WEBKIT_ was not declared… so I disabled webkit in wxwidgets above. -ld: file not found: undefined =change -Wl,undefined to -Wl,-undefined in linkCxxOpts in Setup.hs installing wxcore -* Missing C library: wxc name is wxc.so instead of libwxc.dylib =change for sharedLibName: OSX - lib ++ addExtension basename .dylib in Setup.hs ghc --make HelloWorld.hs Undefined symbols for architecture x86_64: _expEVT_DIALUP_DISCONNECTED I don't know where this is coming from (dialupman is enabled in wxwidgets) so I commented out the DIALUP lines in wxc_glue.h ./HelloWorld - dlopen(dist/build/libwxc.dylib) failed The final problem is that a dylib contains an absolute paths used for linking, and the library is expected to be found at that locations. To set this path we must pass the -install_name argument when linking libwxc.dylib = OSX - [-dynamiclib, -o ++ out_dir / sharedLibName ver basename, -install_name ++ basepath / sharedLibName ver basename, -Wl,-undefined,dynamic_lookup] in linkCxxOpts, thus needing an extra basepath argument this is found by adding = inst_lib_dir = libdir $ absoluteInstallDirs pkg_descr local_bld_info NoCopyDest to myBuildHook and also using an extra argument for linkSharedLib. Thank you very much for the patch, but I have one tiny request: I can't apply wxhaskell-osx.patch because the structure doesn't match the one on my system. Could you record it with darcs and send the patch bundle as an attachment (darcs send -o mypatch.dpatch) http://darcs.net/manual/Darcs_commands.html#SECTION00661000 http://darcs.net/manual/Darcs_commands.html#SECTION00664000 Also, if you record the patches your name will forever be attached to them and you will received the karma you deserve :) 3) using wxhaskell ghc --make seems to work with the limited testing that I did ghci error: +[NSUndoManager(NSInternal) _endTopLevelGroupings] is only safe to invoke on the main thread. ghci creates a new thread for each computation and under os x the gui apparently must run on the main (first) thread. This is solved by: ghci -fno-ghci-sandbox Another good tip for the wiki perhaps? I wonder if there is a way to indicate at a package level that this is required? However, keyboard input is not directed to the gui but to the ghci terminal… There used to be an EnableGUI module to fix this (http://www.haskell.org/haskellwiki/WxHaskell/MacOS_X), but that does not seem to work anymore. The window can be closed and restarted from ghci though. However, the
Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell
Hi Dave, all, This is fantastic news - especially the bit about GHCi. I have put a couple of general comments inline, but it looks like you have found most of the issues, at least on Linux. I think that at least some of the issues would go away if, as you say, *we could have an entirely separate cabal project (perhaps wxc) for this shared library, and then have wxcore depend on it? * In this case, we would be able to ensure that libwxc.so.x.y.z (or wxc.dll or libwxc.dylib or whatever) was in a 'normal' place before wxcore gets built. On 9 December 2011 14:13, Dave Tapley duked...@gmail.com wrote: On 8 December 2011 22:34, Dave Tapley duked...@gmail.com wrote: Hello everyone, I wrote a story, and I invite you all to comment and help me make it better. As an experiment I've decided to put it on hpaste instead of having the mail thread get out of hand (I'm also cross posting it to the cabal list and have mentioned it in #haskell, and I want to keep all correspondence in one place): http://hpaste.org/55027 Ha, well that was good timing for hpaste to go down! Here's it is: I've been trying to resurrect the idea of building a shared library for the C++ component of the wxhaskell library. Jeremy (to my knowledge) first put this forward, here: http://wewantarock.wordpress.com/2010/11/01/working-around-the-static-libstdc-restriction/ In addition to the advantages he lists there, I have the following reason: When building wx-core (in its current incarnation) cabal will *always* rebuild all the C++ code, which takes a majority of the build time. This becomes very frustrating when you change one line of Haskell and have to wait seven minutes to rebuild. I complained about it here: http://sourceforge.net/mailarchive/message.php?msg_id=2807 So, I decided to try and stop this complete C++ rebuild, I partially succeed, but I eventually got stuck for reasons I complained here: http://www.haskell.org/pipermail/cabal-devel/2011-October/007816.html Side note: I did eventually discover why (or, where) the c-sources (cSources) list is used to compile and link, and it is here: http://hackage.haskell.org/packages/archive/Cabal/latest/doc/html/src/Distribution-Simple-GHC.html#buildLib You can see: | filename - cSources libBi] under -- build any C sources, and you can see: cSharedObjs = map (`replaceExtension` (dyn_ ++ objExtension)) (cSources libBi) under -- link:. Is this assumption correct? This is correct - it's the standard way Cabal builds C/C++ code. To be honest, this is really a consequence of the fact that Cabal is more of a tool for simple distribution than a Make replacement, and the developers probably didn't expect Cabal would be used to build large bodies of C++ code. My approach is far from perfect, too - in fact it is incorrect because I don't do dependency tracking on header files, so if you edit a header, it (incorrectly) fails to rebuild. This is because I wasn't keen on rewriting 'make' in the wxHaskell build system - it seems to me like something Cabal could usefully support. I did play with some very hacky code which automatically rebuilt all of the C++ code if any header is newer than any C++ source. This is aesthetically dreadful, but it somewhat captures the reality, since in practice, pretty much all of the C++ files depend on all of the headers (and it's easy to write). On reflection, we should probably do this as what exists at present could lead to unexpectedly incorrect code being generated if someone is in full flow of development. I'll see if I can dig up some code - I think I have it somewhere. At this point I thought about either: 1. Getting the cabal source and starting to write code to give BuildInfo a cObjs in addition to cSources. 2. Picking up Jeremy's shared library code, so wxhaskell would have its own code to build the library, in which I could do sensible re-compilation. Given that there were other advantages to 2, I went with that. Jeremy had written one blog post on building a such a shared library, here: http://wewantarock.wordpress.com/2010/11/03/building-a-shared-library-in-cabal/ In response to an email on the wxhaskell-devel list he also kindly put up this gist, with the code he'd been working on: https://gist.github.com/1301115 I dutifully took this gist, and have now attempted to integrate in to my wxhaskell-dev branch, which you can find here: http://darcsden.com/DukeDave/wxhaskell-dev (note: I haven't pushed any of the shared library code to darcsden yet, for reasons I'm about to explain) This is where things got interesting, after a few hours of hacking I have built a shared library, but in this very back-handed way: Firstly, in Jeremy's code the to-be-compiled shared library is added to the wxcore BuildInfo through a custom hook. We can see this because: let all_dlls = parseDLLs [x-dll-name, x-dll-extra-libraries] custom_bi (the modified wxcore.cabal contains the line:
Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell
On 12 December 2011 17:18, Jeremy O'Donoghue jeremy.odonog...@gmail.com wrote: Hi Dave, all, This is fantastic news - especially the bit about GHCi. I have put a couple of general comments inline, but it looks like you have found most of the issues, at least on Linux. I think that at least some of the issues would go away if, as you say, we could have an entirely separate cabal project (perhaps wxc) for this shared library, and then have wxcore depend on it? In this case, we would be able to ensure that libwxc.so.x.y.z (or wxc.dll or libwxc.dylib or whatever) was in a 'normal' place before wxcore gets built. On 9 December 2011 14:13, Dave Tapley duked...@gmail.com wrote: On 8 December 2011 22:34, Dave Tapley duked...@gmail.com wrote: Hello everyone, I wrote a story, and I invite you all to comment and help me make it better. As an experiment I've decided to put it on hpaste instead of having the mail thread get out of hand (I'm also cross posting it to the cabal list and have mentioned it in #haskell, and I want to keep all correspondence in one place): http://hpaste.org/55027 Ha, well that was good timing for hpaste to go down! Here's it is: I've been trying to resurrect the idea of building a shared library for the C++ component of the wxhaskell library. Jeremy (to my knowledge) first put this forward, here: http://wewantarock.wordpress.com/2010/11/01/working-around-the-static-libstdc-restriction/ In addition to the advantages he lists there, I have the following reason: When building wx-core (in its current incarnation) cabal will *always* rebuild all the C++ code, which takes a majority of the build time. This becomes very frustrating when you change one line of Haskell and have to wait seven minutes to rebuild. I complained about it here: http://sourceforge.net/mailarchive/message.php?msg_id=2807 So, I decided to try and stop this complete C++ rebuild, I partially succeed, but I eventually got stuck for reasons I complained here: http://www.haskell.org/pipermail/cabal-devel/2011-October/007816.html Side note: I did eventually discover why (or, where) the c-sources (cSources) list is used to compile and link, and it is here: http://hackage.haskell.org/packages/archive/Cabal/latest/doc/html/src/Distribution-Simple-GHC.html#buildLib You can see: | filename - cSources libBi] under -- build any C sources, and you can see: cSharedObjs = map (`replaceExtension` (dyn_ ++ objExtension)) (cSources libBi) under -- link:. Is this assumption correct? This is correct - it's the standard way Cabal builds C/C++ code. To be honest, this is really a consequence of the fact that Cabal is more of a tool for simple distribution than a Make replacement, and the developers probably didn't expect Cabal would be used to build large bodies of C++ code. My approach is far from perfect, too - in fact it is incorrect because I don't do dependency tracking on header files, so if you edit a header, it (incorrectly) fails to rebuild. This is because I wasn't keen on rewriting 'make' in the wxHaskell build system - it seems to me like something Cabal could usefully support. I did play with some very hacky code which automatically rebuilt all of the C++ code if any header is newer than any C++ source. This is aesthetically dreadful, but it somewhat captures the reality, since in practice, pretty much all of the C++ files depend on all of the headers (and it's easy to write). On reflection, we should probably do this as what exists at present could lead to unexpectedly incorrect code being generated if someone is in full flow of development. I'll see if I can dig up some code - I think I have it somewhere. You know, I'm surprised this didn't occur to me until now: Does the C++ code actually need to use cabal at all? If it's a separate project, perhaps it would be more sensible to use a C++ oriented build system? Then, unless I'm missing something, it can install the headers somewhere, and wxcore can run wxdirect on the headers are currently. The big disadvantage I can see with moving the C++ out of the wxcore project is lots of pain for users when they 'cabal update' and suddenly wxcore fails because they need to update the C++ headers / library. Another disadvantage is that this will make development a little more painful (although the time saved not having to rebuild all the C++ is a huge bonus) because you wouldn't (without some hackery) be able to use cabal-dev as described here: http://haskell.org/haskellwiki/WxHaskell/Development/Environment#Building_and_testing_wxHaskell I happened upon this (dead) project, which I seems to have the goal I am outlining: http://wxc.sourceforge.net/ At this point I thought about either: 1. Getting the cabal source and starting to write code to give BuildInfo a cObjs in addition to cSources. 2. Picking up Jeremy's shared library code, so wxhaskell would have its own code to build the library,
