ImportC Rox

[Don Allen]

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:
>> https://news.ycombinator.com/item?id=33509223
>

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.