Permalink
Reply
On Wednesday, 9 November 2022 at 15:00:39 UTC, Don Allen wrote:
>On Monday, 7 November 2022 at 22:05:38 UTC, Walter Bright wrote:
>I'm old enough to know that when something seems to be too good to be true, it's probably too good to be true. Unfortunately, I missed this one; my amazement at "how easy it was" was caused by my own error. When I made the first attempt to build my application using ImportC, I had failed to remove my old gtk.d file from the source directory. That is the file that contains all my hand-coded definitions I spoke of in my original post. So the imports of gtk in my source files saw that file and so I was unknowingly repeating my old build method without any use of ImportC.
When I removed that file and tried to rebuild, life got more complicated.
My first issue was that I don't believe that my interpretation of Walter's statement (in his post to ycombinator news) was correct -- I don't think you can directly include C header files in D code. I now believe that the documentation in 41.3.2 is correct.
Once I came to that realization, I created a gtk.c file in a place visible to my source files containing just one line:
#include <gtk/gtk.h>
and then arranged for the clang pre-processor to produce a gtk.i file from it, using the standard pkg-conf method to tell Clang where all the gtk header-file directories are. The 'import gtk's in my D source files now see the gtk.i file and so I am now actually using ImportC, rather than imagining it. The problem is that it produces many errors, due to the expansion of gtk.h generating a lot of C that ImportC doesn't understand.
I tried modifying my gtk.c in an attempt to work around some of the problems, using #defines, a technique suggested in Walter's documentation. This helped, but ultimately, it just kicks the can down the road. The fundamental problem is that the expansion of gtk.h is extremely complex and, crucially, makes use of gcc and/or clang extensions that I could not work around; they are just too far from C11 or too difficult to modify. So to continue to use D, I will have to revert to my original method for dealing with gtk.
I don't think this experience invalidates the ImportC idea, because it seems very clear that gtk is an extreme case. In fact, my application also uses sqlite and I am going to try to use ImportC to deal with that. My hope is that the sqlite header files generate code closer to the C that ImportC supports. What I've learned from the experience I've just described will allow me to test that theory pretty quickly. I will let you know how that goes.
I did see one possible issue that may be worthy of a bug report. I need to investigate this one further and will write the report if I think it's a real problem.
