Hi Dave,

On 20 September 2011 17:58, Dave Tapley <dukedave@gmail.com> wrote:
On 16 September 2011 23:30, Dave Tapley <dukedave@gmail.com> wrote:
I presume everyone has a very long compile time when building wxcore?
Specifically rebuilding everything under src/cpp/ every time..

Has anyone ever looked into avoiding this complete rebuild?

I've just spent a few hours looking deeper in to this and come across two issues:

1. There is a very informative blog post[1] written by Jeremy, which deals with the subject of "Compiling C or C++ code from within Cabal". Unfortunately I can't find any of the code mentioned in the post in the project, specifically I tried to find a "myBuildHook" in "./wxcore/Setup.hs" (I also looked in previous revisions using a trackdown grep[2]) but I didn't find anything. Perhaps someone with better knowledge of the project can comment on if/where/when the code in the post was used?

The code sits on my development machine. It works, but with a fairly serious limitation.

The limitation is that I do not do any dependency tracking. It works by checking if an object file is older than its corresponding source file. This works fine for .cpp files but breaks if you change a header. Short of writing a complete dependency tracker, this is hard to fix, and in truth I think it belongs in Cabal.

If Cabal wants to say that it can compile C/C++ code, it should be the one to do so correctly, especially as dependency tracking for C/C++ is vile and compiler dependent(*).

I would be very happy to put the code out there as a GitHub gist or similar - it's only in one or two files, and quite easy to follow, but I don't feel it is ready for prime time due to the limitations noted above.
 
(*) one option might be to do this only for GCC, as in practice we only really support GCC anyway.

2. Inspecting the wxdirect code you can see that "System.IO.writeFile" is used to write all the generated code[3], but no test is performed to see if the output file has actually changed. Thus the file is always opened for write, and so its modification time is changed, and so everything is recompiled every time wxcore is built. I have have written a local patch which replaces the "writeFile" function with one which first checks whether the string to be written differs (aside from date/time stamp) to the current one; it only performs the "writeFile" if there has been a change.
Using this patch none of the Haskell code is re-built, but unfortunately all the C++ code is.

This is a nice patch - I think we should apply it.

Jeremy