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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021