www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - built in import c header files

reply RazvanN <razvan.nitu1305 gmail.com> writes:
https://forum.dlang.org/post/txdjmjkhradboqfmozlm forum.dlang.org

On Tuesday, 6 October 2020 at 20:59:54 UTC, 12345swordy wrote:
 I remember reading a reddit comment saying that if d were to 
 import c header files directly without any 3rd party libraries 
 it would be a game changer. The question is: how difficult to 
 implement a C AST parser for the dmd front end?


 -Alex
As suggested by other participants to this thread, using libclang is the way to go. There really isn't any benefit in having a builtin C parser in dmd. Instead of working on this, I suggest to try to improve dpp as it is easy to install and use. At UPB we have integrated a D driver in the linux kernel. Initially, we could not use dpp due to the complexity and oddity of the C code used in the kernel, so we translated the header files by hand: it was a nightmare. As Atila pointed out, there was an endless stream of dependencies. After the project was finished, we took on the responsibility to try to make dpp work with the linux kernel. We fixed tens of corner case and it looked like dpp could handle all of the cases, however we then stumbled upon a memory issue due to some bug in std.appender (used internally by dpp). Unfortunately, the student working on fixing dpp abandoned the project at that point, but we are very close to making dpp work with the linux kernel. If that works, I assure you that dpp will work in 99% of the cases. Bottom line: it is better to improve dpp than to implement a C parser (when libclang already does that for you) RazvanN
Apr 22
next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Thursday, 22 April 2021 at 07:34:42 UTC, RazvanN wrote:
 https://forum.dlang.org/post/txdjmjkhradboqfmozlm forum.dlang.org

 On Tuesday, 6 October 2020 at 20:59:54 UTC, 12345swordy wrote:
 [...]
As suggested by other participants to this thread, using libclang is the way to go. There really isn't any benefit in having a builtin C parser in dmd. Instead of working on this, I suggest to try to improve dpp as it is easy to install and use. [...]
How in the world did this thread got split? -Alex
Apr 22
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 22 April 2021 at 07:34:42 UTC, RazvanN wrote:
 https://forum.dlang.org/post/txdjmjkhradboqfmozlm forum.dlang.org

 On Tuesday, 6 October 2020 at 20:59:54 UTC, 12345swordy wrote:
 [...]
As suggested by other participants to this thread, using libclang is the way to go. There really isn't any benefit in having a builtin C parser in dmd. Instead of working on this, I suggest to try to improve dpp as it is easy to install and use. [...]
Whoa, that sounds really interesting, I hope you can make dpp even better ☀️
Apr 22
prev sibling next sibling parent russhy <russhy gmail.com> writes:
On Thursday, 22 April 2021 at 07:34:42 UTC, RazvanN wrote:
 https://forum.dlang.org/post/txdjmjkhradboqfmozlm forum.dlang.org

 On Tuesday, 6 October 2020 at 20:59:54 UTC, 12345swordy wrote:
 I remember reading a reddit comment saying that if d were to 
 import c header files directly without any 3rd party libraries 
 it would be a game changer. The question is: how difficult to 
 implement a C AST parser for the dmd front end?


 -Alex
As suggested by other participants to this thread, using libclang is the way to go. There really isn't any benefit in having a builtin C parser in dmd. Instead of working on this, I suggest to try to improve dpp as it is easy to install and use. At UPB we have integrated a D driver in the linux kernel. Initially, we could not use dpp due to the complexity and oddity of the C code used in the kernel, so we translated the header files by hand: it was a nightmare. As Atila pointed out, there was an endless stream of dependencies. After the project was finished, we took on the responsibility to try to make dpp work with the linux kernel. We fixed tens of corner case and it looked like dpp could handle all of the cases, however we then stumbled upon a memory issue due to some bug in std.appender (used internally by dpp). Unfortunately, the student working on fixing dpp abandoned the project at that point, but we are very close to making dpp work with the linux kernel. If that works, I assure you that dpp will work in 99% of the cases. Bottom line: it is better to improve dpp than to implement a C parser (when libclang already does that for you) RazvanN
In that regard, i think Zig people have done an amazing at being able to transparently consume C code
Apr 22
prev sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Thursday, 22 April 2021 at 07:34:42 UTC, RazvanN wrote:
 https://forum.dlang.org/post/txdjmjkhradboqfmozlm forum.dlang.org

 On Tuesday, 6 October 2020 at 20:59:54 UTC, 12345swordy wrote:
 I remember reading a reddit comment saying that if d were to 
 import c header files directly without any 3rd party libraries 
 it would be a game changer. The question is: how difficult to 
 implement a C AST parser for the dmd front end?


 -Alex
As suggested by other participants to this thread, using libclang is the way to go. There really isn't any benefit in having a builtin C parser in dmd. Instead of working on this, I suggest to try to improve dpp as it is easy to install and use. At UPB we have integrated a D driver in the linux kernel. Initially, we could not use dpp due to the complexity and oddity of the C code used in the kernel, so we translated the header files by hand: it was a nightmare. As Atila pointed out, there was an endless stream of dependencies. After the project was finished, we took on the responsibility to try to make dpp work with the linux kernel. We fixed tens of corner case and it looked like dpp could handle all of the cases, however we then stumbled upon a memory issue due to some bug in std.appender (used internally by dpp). Unfortunately, the student working on fixing dpp abandoned the project at that point, but we are very close to making dpp work with the linux kernel. If that works, I assure you that dpp will work in 99% of the cases. Bottom line: it is better to improve dpp than to implement a C parser (when libclang already does that for you) RazvanN
Anyways, I respectfully disagree, d should import c99 standard with no compiler extensions out of the box. Zig can do it, why not d? -Alex
Apr 22
next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Thursday, 22 April 2021 at 19:35:36 UTC, 12345swordy wrote:
 On Thursday, 22 April 2021 at 07:34:42 UTC, RazvanN wrote:
 https://forum.dlang.org/post/txdjmjkhradboqfmozlm forum.dlang.org

 On Tuesday, 6 October 2020 at 20:59:54 UTC, 12345swordy wrote:
 I remember reading a reddit comment saying that if d were to 
 import c header files directly without any 3rd party 
 libraries it would be a game changer. The question is: how 
 difficult to implement a C AST parser for the dmd front end?


 -Alex
As suggested by other participants to this thread, using libclang is the way to go. There really isn't any benefit in having a builtin C parser in dmd. Instead of working on this, I suggest to try to improve dpp as it is easy to install and use. At UPB we have integrated a D driver in the linux kernel. Initially, we could not use dpp due to the complexity and oddity of the C code used in the kernel, so we translated the header files by hand: it was a nightmare. As Atila pointed out, there was an endless stream of dependencies. After the project was finished, we took on the responsibility to try to make dpp work with the linux kernel. We fixed tens of corner case and it looked like dpp could handle all of the cases, however we then stumbled upon a memory issue due to some bug in std.appender (used internally by dpp). Unfortunately, the student working on fixing dpp abandoned the project at that point, but we are very close to making dpp work with the linux kernel. If that works, I assure you that dpp will work in 99% of the cases. Bottom line: it is better to improve dpp than to implement a C parser (when libclang already does that for you) RazvanN
Anyways, I respectfully disagree, d should import c99 standard with no compiler extensions out of the box. Zig can do it, why not d? -Alex
c99 standard compliant header files obviously ;p -Alex
Apr 22
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 22 April 2021 at 19:35:36 UTC, 12345swordy wrote:
 On Thursday, 22 April 2021 at 07:34:42 UTC, RazvanN wrote:
[snip]

 Bottom line: it is better to improve dpp than to implement a C 
 parser (when libclang already does that for you)

 RazvanN
Anyways, I respectfully disagree, d should import c99 standard with no compiler extensions out of the box. Zig can do it, why not d? -Alex
I don't see why it would be a good idea for DMD/GDC to then be dependent on libclang. Zig only has one compiler back end (LLVM) to worry about. A dpp that works for 99% of C code is a pretty great thing. It will only get better as more people use it.
Apr 22
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Thursday, 22 April 2021 at 20:12:07 UTC, jmh530 wrote:
 On Thursday, 22 April 2021 at 19:35:36 UTC, 12345swordy wrote:
 On Thursday, 22 April 2021 at 07:34:42 UTC, RazvanN wrote:
[snip]

 Bottom line: it is better to improve dpp than to implement a 
 C parser (when libclang already does that for you)

 RazvanN
Anyways, I respectfully disagree, d should import c99 standard with no compiler extensions out of the box. Zig can do it, why not d? -Alex
I don't see why it would be a good idea for DMD/GDC to then be dependent on libclang. Zig only has one compiler back end (LLVM) to worry about. A dpp that works for 99% of C code is a pretty great thing. It will only get better as more people use it.
Why do people keep bringing up libclang here? I am not referring to libclang nor dpp as it does more than c here. -Alex
Apr 22
next sibling parent Max Haughton <maxhaton gmail.com> writes:
On Thursday, 22 April 2021 at 23:10:36 UTC, 12345swordy wrote:
 On Thursday, 22 April 2021 at 20:12:07 UTC, jmh530 wrote:
 On Thursday, 22 April 2021 at 19:35:36 UTC, 12345swordy wrote:
 On Thursday, 22 April 2021 at 07:34:42 UTC, RazvanN wrote:
 [...]
Anyways, I respectfully disagree, d should import c99 standard with no compiler extensions out of the box. Zig can do it, why not d? -Alex
I don't see why it would be a good idea for DMD/GDC to then be dependent on libclang. Zig only has one compiler back end (LLVM) to worry about. A dpp that works for 99% of C code is a pretty great thing. It will only get better as more people use it.
Why do people keep bringing up libclang here? I am not referring to libclang nor dpp as it does more than c here. -Alex
Implementing C? Not the end of the world, but still a big job. Implementing a C preprocessor? Nightmare.
Apr 22
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 22 April 2021 at 23:10:36 UTC, 12345swordy wrote:
 [snip]

 Why do people keep bringing up libclang here? I am not 
 referring to libclang nor dpp as it does more than c here.
 -Alex
You brought up Zig. How do you think Zig parses C? Answer: libclang.
Apr 22
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 23 April 2021 at 00:56:57 UTC, jmh530 wrote:
 On Thursday, 22 April 2021 at 23:10:36 UTC, 12345swordy wrote:
 [snip]

 Why do people keep bringing up libclang here? I am not 
 referring to libclang nor dpp as it does more than c here.
 -Alex
You brought up Zig. How do you think Zig parses C? Answer: libclang.
I am more concerns with the ends results rather than the means to achieve said results. -Alex
Apr 22
parent Mike Parker <aldacron gmail.com> writes:
On Friday, 23 April 2021 at 01:54:25 UTC, 12345swordy wrote:
 On Friday, 23 April 2021 at 00:56:57 UTC, jmh530 wrote:
 You brought up Zig. How do you think Zig parses C? Answer: 
 libclang.
I am more concerns with the ends results rather than the means to achieve said results. -Alex
But the means is a very important aspect in terms of maintenance cost. What you're proposing is a maintenance nightmare.
Apr 23