ImportC Rox

[Bowler Hat]

On Saturday, 12 November 2022 at 15:35:03 UTC, Don Allen wrote:
> 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
>>
>
> 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.

Hi Don,

I've looked at this thread for a while now and made several 
attempts at getting it to work. Unfortunately, my experience with 
ImportC follows exactly what you describe.

I'm actually more curious about the details of how you originally 
worked with gtk in D. I've tried the same method with some 
success but its not entirely obvious how you deal with certain 
cases. For example, g_signal_connect is actually a macro for 
calling another function with specific parameters. That seems to 
have no direct equivalent in D.