Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell
On 12 December 2011 17:18, Jeremy O'Donoghue 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 wrote:
>>
>> On 8 December 2011 22:34, Dave Tapley 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.
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 wrote:
> On 8 December 2011 22:34, Dave Tapley 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"
