On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote:
> Here's my blog post about my project that allows directly #including C headers in D*
>
> https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/
>
> The summary is that, modulo bugs, things like this work:
>
>     #include <stdio.h>
>     void main() { printf("Hello world\n".ptr); }
>
> So far it's successfully compiled whilst #including pthread, libcurl, openssl and others. The blog and the github README have more information, and feel free to reply to this with questions.
>
> dub: http://code.dlang.org/packages/dpp
> reddit: https://www.reddit.com/r/programming/comments/8axj53/include_c_headers_in_d_code/
> hacker news: It's in there somewhere, search around.
>
> Atila
>
> * Technically, "D + #include directives + C macros"

This is really cool. This can be _very_ useful in situations where you don't want to translate all the headers to D, especially when experimenting with C libs. Really cool. Thanks.

On Saturday, 14 April 2018 at 04:07:12 UTC, Petar Kirov [ZombineDev] wrote:
> On Friday, 13 April 2018 at 10:31:43 UTC, Atila Neves wrote:
>> On Wednesday, 11 April 2018 at 14:33:26 UTC, Jacob Carlborg wrote:
>>> On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote:
>>>> Here's my blog post about my project that allows directly #including C headers in D*
>>>
>>> I don't know the exact details of your project but can't you just:
>>>
>>> 1. Copy the includes
>>> 2. Paste them into a C file
>>> 3. Run DStep on the C file
>>> 4. Replace the includes in the first file with the result from DStep
>>>
>>> This would require changing DStep to always return `false` here [1]. Or perhaps run the preprocessor to expand the includes and then run DStep.
>>>
>>> [1] https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/Translator.d#L326
>>>
>>> --
>>> /Jacob Carlborg
>>
>> That wouldn't have the same semantics as I want.
>>
>> I tried using dstep as a library. It didn't work.
>
> You also mentioned this in the reddit thread, though I'm still curious to understand what's difference in the semantics between the approach you have taken and the approach Jacob proposed.

You can use the C macros in the headers that you #include in your dpp file.

dstep has a lot of code for translating macros. I don't want to translate macros at all, but it's deeply intertwined with translating everything else. This bug just can't happen with the dpp approach:

https://github.com/jacob-carlborg/dstep/issues/166

In the idea above it assumes that all #include directives are together at the top of the file. They probably are, but they might not be for some reason. I can't remember the specifics, but dstep by default ignores declarations from other headers because the idea is to translate this one particular header. I don't want that either. I also don't want D code generated that has an `import` to a D file that's actually a translation of another C header.

I want it to work like it does in C++. dstep doesn't set out to do that, which is fine, but contorting it to make it do what I wanted it to was more trouble than it was worth.

Believe me, if I can avoid writing code, I do. Writing translations from scratch was not a decision I made lightly. In the end it turned out to be a lot less work than I thought though (just over 500 SLOC).


Atila

On Monday, 16 April 2018 at 11:20:51 UTC, Atila Neves wrote:

> You can use the C macros in the headers that you #include in your dpp file.
>
> dstep has a lot of code for translating macros. I don't want to translate macros at all, but it's deeply intertwined with translating everything else.

There's a command line switch to disable that, `--translate-macros=false`. Or, alternatively, run the preprocessor first.

> I can't remember the specifics, but dstep by default ignores declarations from other headers because the idea is to translate this one particular header.

That's a simple change: replace these lines [1] with `return false;`. If that's something you need we can make it configurable.

[1] https://github.com/jacob-carlborg/dstep/blob/97870ac5167f09e8acf17f8754c32636492b237f/dstep/translator/Translator.d#L326-L329

--
/Jacob Carlborg

On Monday, 16 April 2018 at 12:26:12 UTC, Jacob Carlborg wrote:
> On Monday, 16 April 2018 at 11:20:51 UTC, Atila Neves wrote:
>
>> You can use the C macros in the headers that you #include in your dpp file.
>>
>> dstep has a lot of code for translating macros. I don't want to translate macros at all, but it's deeply intertwined with translating everything else.
>
> There's a command line switch to disable that, `--translate-macros=false`. Or, alternatively, run the preprocessor first.

I missed that.

>
>> I can't remember the specifics, but dstep by default ignores declarations from other headers because the idea is to translate this one particular header.
>
> That's a simple change: replace these lines [1] with `return false;`. If that's something you need we can make it configurable.
>
> [1] https://github.com/jacob-carlborg/dstep/blob/97870ac5167f09e8acf17f8754c32636492b237f/dstep/translator/Translator.d#L326-L329

No need to make it configureable now - I did the translation work already and made a point of copying in dstep's tests to guarantee the same level of support. Given how small it ended up being, I'd trade ~500SLOC over a dependency nearly every time.

I also like the end result better (unsurprising since I wrote it), even though I didn't quite achieve the level of testability I wanted.