www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - ImportC Rox

reply Walter Bright <newshound2 digitalmars.com> writes:
https://news.ycombinator.com/item?id=33509223
Nov 07 2022
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 7 November 2022 at 22:05:38 UTC, Walter Bright wrote:

 https://news.ycombinator.com/item?id=33509223


💘
Nov 08 2022
prev sibling next sibling parent reply Don Allen <donaldcallen gmail.com> writes:
On Monday, 7 November 2022 at 22:05:38 UTC, Walter Bright wrote:

 https://news.ycombinator.com/item?id=33509223


The main application in the suite of financial tools I built for 
myself and ported to D from C uses the gtk3 and sqlite3 C 
libraries. Let's talk about gtk, which is a big system and has 
many convoluted and complex header files.

I dealt with gtk in my D code as you might expect. I created a 
gtk.d with hand-coded definitions and function prototypes such as
````
alias gconstpointer = immutable(void) *;

struct GtkWindow; // All structs that are dealt with by pointer 
only are defined this way

struct GtkTreeIter {
     long[4] dontcare;
} /* A few structs like this need to be stack-allocated in D 
code, their addresses
      passed to gtk functions. I check their sizes against globals 
containing
      sizeofs in a the lone C file that is part of this 
application */

extern (C) void gtk_tree_selection_select_iter(GtkTreeSelection* 
selection, GtkTreeIter* iter);
````
This is the standard pre-ImportC approach. Messy and ugly, but it 
works. However, if the library functions and C header files 
change, the application will break in unpredictable and 
hard-to-debug ways. At the moment, I'm using gtk3, which will not 
change because they've moved on to gtk4 with a somewhat different 
API. But if I decide to update to gtk4, I would be subject to 
this risk using this method.

I read the ImportC documentation when it first became available 
and several times since. I did not come away from those readings 
with a clear idea of how to use it to rid myself of the above. 
Then I saw Walter's comment in the link above. Aha -- you can 
just import header files in D code! The documentation does not 
say that, unless I've missed something. I think the relevant 
section is 41.3.2, which, given 'import hello', says "which will, 
if hello is not a D file, and has an extension .i or .c, compile 
hello with ImportC". No mention of .h files. Walter's comment 
made two things clear -- how to use ImportC in my case and that 
the documentation needs to be corrected and improved with an 
example of importing a C header file. Importing header files so 
you can directly use C libraries is a major reason why ImportC is 
an important addition to D and it should be crystal clear in the 
documentation how to do it.

With my improved understanding, I decided to give ImportC a try. 
All my D source files already had 'import gtk' statements, to get 
at my hand-coded definitions above. So no change was needed, 
since the goal was now to import gtk.h. I simply changed my 
makefile for this application to, in the invocations of dmd that 
compile my D source files, include the standard pkg-conf call 
that expands primarily into '-I's, indicating where to find all 
the gtk header files. A little post-processing of that expansion 
was necessary with sed, because dmd expects -I in a slightly 
different format than clang. I also needed to remove a couple of 
switches that dmd doesn't support.

I also removed the checks on struct sizes (and their definitions 
in my C file), since the struct definitions are now available 
directly from the Gtk header files.

Then I got rid of all references in the makefile to my gtk.d 
source file. After a few false starts due to things I overlooked, 
the application built successfully. This all took less than an 
hour. I've done some cursory testing and it seems to work 
properly. I was quite amazed at how easy this was.

So based on my initial experience, Walter's statement about 
ImportC's usefulness seems to be correct (I will report if 
anything turns up in more thorough testing) and I congratulate 
him for this work; it really facilitates the use of C libraries. 
I think this should be prominent in any "Why D?" presentation or 
discussion, because ImportC greatly enhances D's competitive 
position, in my opinion. Marketing!

I will add that I've played with zig a bit, starting a couple of 
years ago, attracted by its translate-c capability, which is 
analogous to ImportC. At that time, I remember looking at D as a 
candidate for the work I wanted to do and being put off by the 
realization that to use it, I would need to do something like the 
above hackery. I did eventually come back to D despite this, 
because Zig was and is not ready and because of my misadventures 
with Rust, which I've already discussed in other posts.
Nov 09 2022
next sibling parent Sergey <kornburn yandex.ru> writes:
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 read the ImportC documentation when it first became available 
 and several times since. I did not come away from those 
 readings with a clear idea of how to use it to rid myself of 
 the above. Then I saw Walter's comment in the link above. Aha 
 -- you can just import header files in D code! Walter's comment 
 made two things clear -- how to use ImportC in my case and that 
 the documentation needs to be corrected and improved with an 
 example of importing a C header file. Importing header files so 
 you can directly use C libraries is a major reason why ImportC 
 is an important addition to D and it should be crystal clear in 
 the documentation how to do it.


This shows that we need HOWTO or tutorial with explanation of 
possible usage and how to deal with possible problems.
Nov 09 2022
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 9 November 2022 at 15:00:39 UTC, Don Allen wrote:

 [snip]


Great write-up!
Nov 09 2022
prev sibling next sibling parent bachmeier <no spam.net> writes:
On Wednesday, 9 November 2022 at 15:00:39 UTC, Don Allen wrote:

[...]

I was going to say this would make a nice blog post. Then I 
realized it was a blog post, just not on a blog.

[D subreddit 
link](https://www.reddit.com/r/d_language/comments/yqogo0/using_importc_with_a_gtk_application/?)
Nov 09 2022
prev sibling next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 11/9/22 07:00, Don Allen wrote:


 This is the standard pre-ImportC approach. Messy and ugly, but it works.


Yes, there are issues with non-standard solutions: People have to repeat 
each other, don't know about existing solutions, there is a different 
kind of learning curve, etc.

For example, there is

   https://gtkd.org/

and I had watched Gerald Nunn's presentation:

   https://dconf.org/2017/talks/nunn.html

but I can't be sure without researching even whether gtkd is the same 
thing that was covered in that presentation.

Then there are dpp, DStep, etc. (which I "remembered" their names only 
by visiting the ImportC page).

It is similar with unit testing: I can't even remember what framework I 
had settled on during my C++ days but I will never forget the keyword 
'unittest'.

So, yes, I am convinced that a native solution enables so much for so 
many people.


 The documentation does not say that, unless I've missed
 something.


Yes, other parts of the spec can be improved but the "spec" for this 
young feature is here:

   https://dlang.org/spec/importc.html


 This all took less than an hour. I've
 done some cursory testing and it seems to work properly. I was quite
 amazed at how easy this was.


Thank you for reporting your experince. I am guessing all this happened 
after the DConf Online submission deadline so we will see you explain it 
at the next in-person DConf. :)

Ali
Nov 09 2022
prev sibling next sibling parent reply Don Allen <donaldcallen gmail.com> writes:
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





 So based on my initial experience, Walter's statement about 
 ImportC's usefulness seems to be correct (I will report if 
 anything turns up in more thorough testing)


Not too surprisingly, given how new ImportC is, more testing 
*has* resulted in problems. I'll have more to say if/when I 
better understand the issue(s).
Nov 09 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/9/2022 10:54 AM, Don Allen wrote:

 Not too surprisingly, given how new ImportC is, more testing *has* resulted in 
 problems. I'll have more to say if/when I better understand the issue(s).


Please post any problems to bugzilla, and tag them with ImportC. Thanks!
Nov 09 2022
parent reply Don Allen <donaldcallen gmail.com> writes:
On Wednesday, 9 November 2022 at 21:00:11 UTC, Walter Bright 
wrote:

 On 11/9/2022 10:54 AM, Don Allen wrote:

 Not too surprisingly, given how new ImportC is, more testing 
 *has* resulted in problems. I'll have more to say if/when I 
 better understand the issue(s).


 Please post any problems to bugzilla, and tag them with 
 ImportC. Thanks!


I will. I'm still working on trying to sort this out (with 
limited time at the moment), so that if a bugzilla report is 
appropriate, it will be useful.
Nov 11 2022
parent reply Don Allen <donaldcallen gmail.com> writes:
On Friday, 11 November 2022 at 15:04:36 UTC, Don Allen wrote:

 On Wednesday, 9 November 2022 at 21:00:11 UTC, Walter Bright 
 wrote:

 On 11/9/2022 10:54 AM, Don Allen wrote:

 Not too surprisingly, given how new ImportC is, more testing 
 *has* resulted in problems. I'll have more to say if/when I 
 better understand the issue(s).


 Please post any problems to bugzilla, and tag them with 
 ImportC. Thanks!


 I will. I'm still working on trying to sort this out (with 
 limited time at the moment), so that if a bugzilla report is 
 appropriate, it will be useful.


     Incidental to the issues I've encountered, I should mention 
that the second ImportC example
     in Quick Examples, Section 41.1, does not compile with either 
the current release of dmd or the release candidate, due to the 
conflict between the module and function names:

     (dmd-2.101.0-rc.1)dca giovanni:/tmp$ dmd demo.d square.c
     demo.d(6): Error: function expected before `()`, not `module 
square` of type `void`

Changing the D code to use the fully qualified function name

     import std.stdio;
     import square;
     void main()
     {
         int i = 7;
         writefln("The square of %s is %s", i, square.square(i));
     }

fixes it. I will file a bugzilla report.
Nov 11 2022
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/11/2022 8:50 AM, Don Allen wrote:

 fixes it. I will file a bugzilla report.


Thank you!
Nov 11 2022
prev sibling parent reply confuzzled <con fuzzled.com> writes:
Don, do you mind helping me out a little? I'm trying to link up 
to and compile an xlsxio example and am making no progress. The 
linker is not finding all the libraries. I'm currently hunting 
down each one and copying them into my working directory and 
inserting a progma(lib, "libname.a") statement for each. After 
adding each one, it spits out another set of undefined symbols. 
Somehow this just feels like I'm doing something wrong but am not 
sure what.

I would appreciate any assistance/guidance you can provide.

Thanks,
confuzzled!!!
Nov 11 2022
parent reply Don Allen <donaldcallen gmail.com> writes:
On Saturday, 12 November 2022 at 04:36:33 UTC, confuzzled wrote:

 Don, do you mind helping me out a little? I'm trying to link up 
 to and compile an xlsxio example and am making no progress. The 
 linker is not finding all the libraries. I'm currently hunting 
 down each one and copying them into my working directory and 
 inserting a progma(lib, "libname.a") statement for each. After 
 adding each one, it spits out another set of undefined symbols. 
 Somehow this just feels like I'm doing something wrong but am 
 not sure what.

 I would appreciate any assistance/guidance you can provide.

 Thanks,
 confuzzled!!!


I'd be happy to try to help, but need a lot more detail about 
what you are doing and I think it would be best to take this 
offline. The forum software claims you can get at my email 
address. Why don't you send me a private message with relevant 
files attached?

/Don
Nov 12 2022
next sibling parent confuzzled <con fuzzled.com> writes:
On Saturday, 12 November 2022 at 16:13:37 UTC, Don Allen wrote:

 On Saturday, 12 November 2022 at 04:36:33 UTC, confuzzled wrote:

 Don, do you mind helping me out a little? I'm trying to link 
 up to and compile an xlsxio example and am making no progress. 
 The linker is not finding all the libraries. I'm currently 
 hunting down each one and copying them into my working 
 directory and inserting a progma(lib, "libname.a") statement 
 for each. After adding each one, it spits out another set of 
 undefined symbols. Somehow this just feels like I'm doing 
 something wrong but am not sure what.

 I would appreciate any assistance/guidance you can provide.

 Thanks,
 confuzzled!!!


 I'd be happy to try to help, but need a lot more detail about 
 what you are doing and I think it would be best to take this 
 offline. The forum software claims you can get at my email 
 address. Why don't you send me a private message with relevant 
 files attached?

 /Don


Don,

My apologies for not responding earlier. I ran with the 
explanation given by Mike and Andrey in this thread:

https://forum.dlang.org/post/ombwclqltsghqnjqraju forum.dlang.org

I was able to get the library built and actually compiled the 
program. Turns out the .configure script for xlsxio builds a 
wonky makefile on osx and wasn't locating all the libraries 
because it was looking in the wrong place. After a whole lot of 
manual configuration I got it to build and produce a .dylib file 
which I linked against without issues from D.

I'm not sure if I did everything correctly though. While the 
example can spit out the names of all sheets in a workbook, I 
cannot get it to display the content of any of the sheets. This 
issue appears in both the original code and the D adoption. I'm 
wondering what I could have done wrong when I changed the 
makefile but haven't gone back to try and figure it out as yet.

Just wanted to say thanks for your assistance.

confuzzled!!!
Nov 25 2022
prev sibling parent confuzzled <con fuzzled.com> writes:
On Saturday, 12 November 2022 at 16:13:37 UTC, Don Allen wrote:

 On Saturday, 12 November 2022 at 04:36:33 UTC, confuzzled wrote:

 Don, do you mind helping me out a little? I'm trying to link 
 up to and compile an xlsxio example and am making no progress. 
 The linker is not finding all the libraries. I'm currently 
 hunting down each one and copying them into my working 
 directory and inserting a progma(lib, "libname.a") statement 
 for each. After adding each one, it spits out another set of 
 undefined symbols. Somehow this just feels like I'm doing 
 something wrong but am not sure what.

 I would appreciate any assistance/guidance you can provide.

 Thanks,
 confuzzled!!!


 I'd be happy to try to help, but need a lot more detail about 
 what you are doing and I think it would be best to take this 
 offline. The forum software claims you can get at my email 
 address. Why don't you send me a private message with relevant 
 files attached?

 /Don


Don,

My apologies for not responding earlier. I ran with the 
explanation given by Mike and Andrey in this thread:

https://forum.dlang.org/post/ombwclqltsghqnjqraju forum.dlang.org

I was able to get the library built and actually compiled the 
program. Turns out the .configure script for xlsxio builds a 
wonky makefile on osx and wasn't locating all the libraries 
because it was looking in the wrong place. After a whole lot of 
manual configuration I got it to build and produce a .dylib file 
which I linked against without issues from D.

I'm not sure if I did everything correctly though. While the 
example can spit out the names of all sheets in a workbook, I 
cannot get it to display the content of any of the sheets. This 
issue appears in both the original code and the D adoption. I'm 
wondering what I could have done wrong when I changed the 
makefile but haven't gone back to try and figure it out as yet.

Just wanted to say thanks for your assistance.

confuzzled!!!
Nov 25 2022
prev sibling next sibling parent zjh <fqbqrr 163.com> writes:
On Wednesday, 9 November 2022 at 15:00:39 UTC, Don Allen wrote:


 ...


It would be `great` if you can write an article and gave a 
detailed introduction about `ImportC`.
I can't access `reddit`.
Nov 09 2022
prev sibling parent reply Don Allen <donaldcallen gmail.com> writes:
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.
Nov 12 2022
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/12/2022 7:35 AM, Don Allen wrote:

 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.


Thank you for the correction.

There are an endless number of C extensions, every C compiler does their own 
thing with this. We've implemented a number of popular ones. We don't want to 
waste time implementing ones that don't matter to our users.

I'd like to take a stab at the ones gtk needs. If you could please post them to 
bugzilla, tagging them with the ImportC keyword, we can have a look at the 
feasibility of implementing them.
Nov 12 2022
parent reply Don Allen <donaldcallen gmail.com> writes:
On Saturday, 12 November 2022 at 18:18:13 UTC, Walter Bright 
wrote:

 On 11/12/2022 7:35 AM, Don Allen wrote:



 I'd like to take a stab at the ones gtk needs. If you could 
 please post them to bugzilla, tagging them with the ImportC 
 keyword, we can have a look at the feasibility of implementing 
 them.


Done.
Nov 14 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/14/2022 8:56 AM, Don Allen wrote:

 Done.


good!
Nov 26 2022
prev sibling parent reply Bowler Hat <stomlins hotmail.com> writes:
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.
Mar 21 2023
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/21/2023 3:56 PM, Bowler Hat wrote:

 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.


Can you please post an example of the gtk.h lines of code that you are having 
difficulty with? Then we can help!
Mar 23 2023
prev sibling next sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Tuesday, 21 March 2023 at 22:56:07 UTC, Bowler Hat wrote:

 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.


```C
#define g_signal_connect(instance, detailed_signal, c_handler, 
data) \
     g_signal_connect_data ((instance), (detailed_signal), 
(c_handler), (data), NULL, (GConnectFlags) 0)
```

These gnome people are weird, it should be a simple function (D):

```D
gulong g_signal_connect(gpointer instance, const gchar 
*detailed_signal, GCallback c_handler, gpointer data)
{
     g_signal_connect_data(instance, detailed_signal, c_handler, 
data, null, 0)
}
```
Mar 23 2023
prev sibling parent Don Allen <donaldcallen gmail.com> writes:
On Tuesday, 21 March 2023 at 22:56:07 UTC, Bowler Hat wrote:

 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.


See the message I posted earlier in this thread (on 11/09/2022). 
It describes my general approach to using gtk3 from D without 
ImportC.

As to g_signal_connect -- yes, it's a C macro and you can't use 
it directly in D. But there are signal-connecting functions in 
gtk3, e.g., g_signal_connect_data, that you can use instead. See 
the gtk documentation. The signal-connecting functions live in 
gobject, so you'll need to go to that section of the 
documentation.
Mar 23 2023
prev sibling next sibling parent reply confuzzled <con fuzzled.com> writes:
On Monday, 7 November 2022 at 22:05:38 UTC, Walter Bright wrote:

 https://news.ycombinator.com/item?id=33509223


So I read the responses to this post along with the [ImportC 
documentation](https://dlang.org/spec/importc.html) and was 
excited to try this out. I first copied hello.c from the docs and 
attempted to compile it with dmd. The result:

```
dmd hello.c
hello.c(1): Error: C preprocessor directive `#include` is not 
supported

hello.c(5): Error: no type for declarator before `return`
hello.c(6): Error: no type for declarator before `}`
```
Hmm... that didn't work. No idea how to fix that either. Let me 
try the next example. Output:

```
dmd demo.d square.c
demo.d(6): Error: function expected before `()`, not `module 
square` of type `void`
```
That didn't work either. But if I replace the call to square() on 
line 6 with square.square(), it works fine.

Now, let's try an actual library. First clone xlsxio from github 
and run ```cd xlsxio; make install```. Next create demo.d:

```d
import xlsxio_read;

void main()
{

}
```

and compile it (I copied the header file into the root project 
directory):

```d
dmd demo.d xlsxio_read.h libxlsxio_read.a
Error: unrecognized file extension h
```
Hmmm... What am I missing?

Thanks,
confuzzled!!!
Nov 10 2022
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 10 November 2022 at 16:25:34 UTC, confuzzled wrote:

 hello.c(1): Error: C preprocessor directive `#include` is not 
 supported


This only works on the dmd master (and maybe the latest beta). It 
hasn't been formally released yet.
Nov 10 2022
parent reply confuzzled <con fuzzled.com> writes:
On Thursday, 10 November 2022 at 16:40:57 UTC, Adam D Ruppe wrote:

 On Thursday, 10 November 2022 at 16:25:34 UTC, confuzzled wrote:

 hello.c(1): Error: C preprocessor directive `#include` is not 
 supported


 This only works on the dmd master (and maybe the latest beta). 
 It hasn't been formally released yet.


Okay, awesome. Installed v2.101.0-rc.1 and the first example now 
compiles without issues. Attempts to use the .h file from xlsxio 
still doesn't work though. Assuming it's in master though. Will 
this be included in the 2.101.0 release?

Thanks,
confuzzled!!!
Nov 10 2022
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 10 November 2022 at 17:10:22 UTC, confuzzled wrote:

 Attempts to use the .h file from xlsxio still doesn't work 
 though.


I'm actually not sure about that but I don't think it will.

The way it works right now si you make a little .c file that just 
#include's the .h file you want, then pass that .c file to the 
compiler.
Nov 10 2022
next sibling parent confuzzled <con fuzzled.com> writes:
On Thursday, 10 November 2022 at 17:18:27 UTC, Adam D Ruppe wrote:

 On Thursday, 10 November 2022 at 17:10:22 UTC, confuzzled wrote:

 Attempts to use the .h file from xlsxio still doesn't work 
 though.


 I'm actually not sure about that but I don't think it will.

 The way it works right now si you make a little .c file that 
 just #include's the .h file you want, then pass that .c file to 
 the compiler.


Sweet. That'll work for now. Thanks Adam.

confuzzled!!!
Nov 10 2022
prev sibling parent bauss <jacobbauss gmail.com> writes:
On Thursday, 10 November 2022 at 17:18:27 UTC, Adam D Ruppe wrote:

 On Thursday, 10 November 2022 at 17:10:22 UTC, confuzzled wrote:

 Attempts to use the .h file from xlsxio still doesn't work 
 though.


 I'm actually not sure about that but I don't think it will.

 The way it works right now si you make a little .c file that 
 just #include's the .h file you want, then pass that .c file to 
 the compiler.


Perhaps D could try to automate this somehow as a "hack" to solve 
the problem.
Nov 11 2022
prev sibling parent Nick Treleaven <nick geany.org> writes:
On Thursday, 10 November 2022 at 17:10:22 UTC, confuzzled wrote:

 Attempts to use the .h file from xlsxio still doesn't work 
 though. Assuming it's in master though. Will this be included 
 in the 2.101.0 release?


Walter has now implemented this in master:
https://issues.dlang.org/show_bug.cgi?id=23479

I'm not sure if it will make the next release.
Nov 13 2022
prev sibling parent IGotD- <nise nise.com> writes:
On Monday, 7 November 2022 at 22:05:38 UTC, Walter Bright wrote:

 https://news.ycombinator.com/item?id=33509223


Back to the original article.

https://faultlore.com/blah/c-isnt-a-language/

The discussion is that C is the lingua franca when it comes FFI. 
This is of course a very limited interface, non standard and full 
of special cases.

Isn't there a room for a common FFI language. Similar to LLVM is 
some kind intermediate language for code generation, why not an 
intermediate language that describes interoperability?

In such language, the exact memory layout of types can be 
described, the type of calling convention etc.. Instead of 
supporting each language, the language could emit a common FFI 
format instead so that other languages can import it.

I have personally never seen such attempt, but I really think 
that could be an interesting project. Maybe you have seen any 
previous attempt?
Nov 12 2022