On Wednesday, 11 April 2018 at 06:24:38 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*
>>
>> https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/
>
> How do you deal with macros containing invalid D code, i.e. `#define foo(T) sizeof(T)`?

https://github.com/atilaneves/dpp/issues/22
https://github.com/atilaneves/dpp/blob/60f98e4fee2fac0117ac430216ef9c5c25c511fe/tests/issues.d#L229
https://github.com/atilaneves/dpp/blob/60f98e4fee2fac0117ac430216ef9c5c25c511fe/source/dpp/cursor/macro_.d#L55

I did the best I could having seen some macros. It's likely there are cases I've missed, or that maybe the translation in the link above doesn't work even for what it's supposed to be doing (I have no confidence about catching all the C casts for instance).

If there are other cases, I'll fix them as they're encountered. It's possible some of them can't be fixed and the user will have to work around them. Right now I have a feeling it will probably be ok. Time will tell (assuming I have users!).

On Wednesday, 11 April 2018 at 09:45:07 UTC, Jonathan M Davis wrote:

> It's one thing for someone who is familiar with D to weigh the options and decide that being tied to ldc is okay. It's quite another to tell someone who isn't familiar with D that in order to use D, they have to use a feature which only works with a specific compiler that is not the reference compiler and which will likely never work with the reference compiler.

It also wouldn't work with GDC. Given that GDC has been added to GCC, it would be a bad idea to tell people they need to use LDC to work with C code.

11.04.2018 15:22, bachmeier пишет:
> On Wednesday, 11 April 2018 at 09:45:07 UTC, Jonathan M Davis wrote:
> ... Given that GDC has been added to GCC...
Is it true? I don't see anything like that here https://gcc.gnu.org/gcc-8/changes.html

On Wednesday, 11 April 2018 at 13:17:23 UTC, drug wrote:
> 11.04.2018 15:22, bachmeier пишет:
>> On Wednesday, 11 April 2018 at 09:45:07 UTC, Jonathan M Davis wrote:
>> ... Given that GDC has been added to GCC...
> Is it true? I don't see anything like that here https://gcc.gnu.org/gcc-8/changes.html

Here's relevant news from Phoronix:

https://www.phoronix.com/scan.php?page=news_item&px=D-Frontend-For-GCC

Here's the relevant announcement:
https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html

11.04.2018 16:26, Uknown пишет:
> On Wednesday, 11 April 2018 at 13:17:23 UTC, drug wrote:
>> 11.04.2018 15:22, bachmeier пишет:
>>> On Wednesday, 11 April 2018 at 09:45:07 UTC, Jonathan M Davis wrote:
>>> ... Given that GDC has been added to GCC...
>> Is it true? I don't see anything like that here https://gcc.gnu.org/gcc-8/changes.html
> 
> Here's relevant news from Phoronix:
> 
> https://www.phoronix.com/scan.php?page=news_item&px=D-Frontend-For-GCC
> 
> Here's the relevant announcement:
> https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html
I've read it. Unfortunately it doesn't answer my question. I've heard there were some problems.

AFAIK, GDC does not make it, so hopefully it will be merge with gcc 9

On Wed, Apr 11, 2018 at 3:44 PM, drug via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> 11.04.2018 16:26, Uknown пишет:
>
> On Wednesday, 11 April 2018 at 13:17:23 UTC, drug wrote:
>>
>>> 11.04.2018 15:22, bachmeier пишет:
>>>
>>>> On Wednesday, 11 April 2018 at 09:45:07 UTC, Jonathan M Davis wrote: ... Given that GDC has been added to GCC...
>>>>
>>> Is it true? I don't see anything like that here https://gcc.gnu.org/gcc-8/changes.html
>>>
>>
>> Here's relevant news from Phoronix:
>>
>> https://www.phoronix.com/scan.php?page=news_item&px=D-Frontend-For-GCC
>>
>> Here's the relevant announcement: https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html
>>
> I've read it. Unfortunately it doesn't answer my question. I've heard there were some problems.
>

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*

BTW, you can steal the config script [1] from DStep to help detect locations of LLVM/libclang. It also supports static linking. Supports manually specifying the path to LLVM if needed.

[1] https://github.com/jacob-carlborg/dstep/blob/master/configure.d

--
/Jacob Carlborg

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

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/
>
Cannot manage to build it on Windows:

D:\git\dpp>dub build
WARNING: A deprecated branch based version specification is used for the dependency libclang. Please use numbered versions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead.
Performing "debug" build using dmd for x86.
libclang ~master: target for configuration "library" is up to date.
dpp 0.0.1+commit.41.g60f98e4: building configuration "executable"...
Linking...
OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
OPTLINK : Warning 183: Extension not .RES : clang.lib
C:\Users\[]\AppData\Roaming\dub\packages\libclang-master\libclang\.dub\build\library-debug-windows-x86-dmd_2079-78261F5A299D700FEEC2C0E7B51191C1\libclang.lib(1) : Error 52: .DEF Syntax Error


D:\git\dpp>dub build --arch=x86_64
WARNING: A deprecated branch based version specification is used for the dependency libclang. Please use numbered versions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead.
Performing "debug" build using dmd for x86_64.
libclang ~master: target for configuration "library" is up to date.
dpp 0.0.1+commit.41.g60f98e4: building configuration "executable"...
Linking...
LINK : fatal error LNK1104: cannot open file 'clang.lib'
Error: linker exited with status 1104
dmd failed with exit code 1.

On 4/11/2018 3:25 AM, Atila Neves wrote:
> I did the best I could having seen some macros. It's likely there are cases I've missed, or that maybe the translation in the link above doesn't work even for what it's supposed to be doing (I have no confidence about catching all the C casts for instance).
> 
> If there are other cases, I'll fix them as they're encountered. It's possible some of them can't be fixed and the user will have to work around them. Right now I have a feeling it will probably be ok. Time will tell (assuming I have users!).


That's right. There is no general solution. One can only look for common patterns and do those. For example,

  #define X 15

is a common pattern and can be reliably rewritten as:

  enum X = 15;