https://gitlab.com/mihails.strasuns/dtoh

Tool to grab all `extern(C)` declarations in a D module and generate C header file based on it. Partially addresses https://issues.dlang.org/show_bug.cgi?id=9285 but is intended to be much more simple (no C++, no human-readable emphasis).

Main differences from version written by Adam some years ago:

- Uses DMD frontend as a library directly
- Has tests

Former is quite intentional decision though I do expect it to be controversial. Using json output requires parsing information that is already present in DMD FE in a strongly typed way - and the only benefit is that the tool becomes more decoupled from compiler. In my opinion, this functionality _should_ be part of compiler itself, similar to .di generation.

Sadly can't put it on code.dlang.org right now because there are no tagged versions of http://code.dlang.org/packages/dmd to depend on, thus have to resort to submodule.

On Wednesday, 22 August 2018 at 11:01:02 UTC, Mihails wrote:
> https://gitlab.com/mihails.strasuns/dtoh

Cool!!

> Sadly can't put it on code.dlang.org right now because there are no tagged versions of http://code.dlang.org/packages/dmd to depend on, thus have to resort to submodule.

Yeah, the dub registry is "smart" enough to reject all tags from the dmd repository as they all don't conform with SemVer.
There has been a long discussion on this (https://forum.dlang.org/post/drcekmxvfszpwifbukzk@forum.dlang.org), but sadly it seems that no consensus has been reached.

On Wednesday, 22 August 2018 at 11:51:59 UTC, Seb wrote:
> Yeah, the dub registry is "smart" enough to reject all tags from the dmd repository as they all don't conform with SemVer.
> There has been a long discussion on this (https://forum.dlang.org/post/drcekmxvfszpwifbukzk@forum.dlang.org), but sadly it seems that no consensus has been reached.

This is a bit sad, because that means no stable tool can be built to use DMD FE as a library as long as it want to be available via code.dlang.org (also afair branch dependencies are deprecated in dub itself now). For dtoh it is probably less of a problem as I intend to propose it for inclusion in dmd if it proves itself good enough in production, but it feels like a missed opportunity overall.

Am 22.08.2018 um 14:32 schrieb Mihails:
> On Wednesday, 22 August 2018 at 11:51:59 UTC, Seb wrote:
>> Yeah, the dub registry is "smart" enough to reject all tags from the dmd repository as they all don't conform with SemVer.
>> There has been a long discussion on this (https://forum.dlang.org/post/drcekmxvfszpwifbukzk@forum.dlang.org), but sadly it seems that no consensus has been reached.
> 
> This is a bit sad, because that means no stable tool can be built to use DMD FE as a library as long as it want to be available via code.dlang.org (also afair branch dependencies are deprecated in dub itself now). For dtoh it is probably less of a problem as I intend to propose it for inclusion in dmd if it proves itself good enough in production, but it feels like a missed opportunity overall.

Can't we at least use something like "0.0.1-dmd-2.080.0" that is sure to not interfere with any official scheme that might be decided on later?

Am 22.08.2018 um 15:59 schrieb Sönke Ludwig:
> Am 22.08.2018 um 14:32 schrieb Mihails:
>> On Wednesday, 22 August 2018 at 11:51:59 UTC, Seb wrote:
>>> Yeah, the dub registry is "smart" enough to reject all tags from the dmd repository as they all don't conform with SemVer.
>>> There has been a long discussion on this (https://forum.dlang.org/post/drcekmxvfszpwifbukzk@forum.dlang.org), but sadly it seems that no consensus has been reached.
>>
>> This is a bit sad, because that means no stable tool can be built to use DMD FE as a library as long as it want to be available via code.dlang.org (also afair branch dependencies are deprecated in dub itself now). For dtoh it is probably less of a problem as I intend to propose it for inclusion in dmd if it proves itself good enough in production, but it feels like a missed opportunity overall.
> 
> Can't we at least use something like "0.0.1-dmd-2.080.0" that is sure to not interfere with any official scheme that might be decided on later?

correction: "0.0.1+dmd-2.080.0"

On Wednesday, 22 August 2018 at 13:59:35 UTC, Sönke Ludwig wrote:
> Can't we at least use something like "0.0.1-dmd-2.080.0" that is sure to not interfere with any official scheme that might be decided on later?

Sounds like a good workaround, though it does have to actually be present as a tag in DMD repo as far as I understand and it will definitely confuse the hell out of random by-passers.

On Wed, 22 Aug 2018 at 04:05, Mihails via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> https://gitlab.com/mihails.strasuns/dtoh
>
> Tool to grab all `extern(C)` declarations in a D module and generate C header file based on it. Partially addresses https://issues.dlang.org/show_bug.cgi?id=9285 but is intended to be much more simple (no C++, no human-readable emphasis).
>
> Main differences from version written by Adam some years ago:
>
> - Uses DMD frontend as a library directly
> - Has tests
>
> Former is quite intentional decision though I do expect it to be controversial. Using json output requires parsing information that is already present in DMD FE in a strongly typed way - and the only benefit is that the tool becomes more decoupled from compiler. In my opinion, this functionality _should_ be part of compiler itself, similar to .di generation.
>
> Sadly can't put it on code.dlang.org right now because there are no tagged versions of http://code.dlang.org/packages/dmd to depend on, thus have to resort to submodule.

This is very topical for me just now... but no extern(C++)??
I have some extern(C++) classes that need to have .h files generated
for them. Is this a goal for the project?

On 2018-08-22 13:01, Mihails wrote:
> https://gitlab.com/mihails.strasuns/dtoh
> 
> Tool to grab all `extern(C)` declarations in a D module and generate C header file based on it. Partially addresses https://issues.dlang.org/show_bug.cgi?id=9285 but is intended to be much more simple (no C++, no human-readable emphasis).
> 
> Main differences from version written by Adam some years ago:
> 
> - Uses DMD frontend as a library directly
> - Has tests
> 
> Former is quite intentional decision though I do expect it to be controversial. Using json output requires parsing information that is already present in DMD FE in a strongly typed way - and the only benefit is that the tool becomes more decoupled from compiler. In my opinion, this functionality _should_ be part of compiler itself, similar to .di generation.
> 
> Sadly can't put it on code.dlang.org right now because there are no tagged versions of http://code.dlang.org/packages/dmd to depend on, thus have to resort to submodule.

Iain has a PR in DMD for generating C++ headers from extern(C++) declarations [1]. Perhaps join forces on this.

[1] https://github.com/dlang/dmd/pull/8591

-- 
/Jacob Carlborg

On Wednesday, 22 August 2018 at 19:13:37 UTC, Jacob Carlborg wrote:
> Iain has a PR in DMD for generating C++ headers from extern(C++) declarations [1]. Perhaps join forces on this.
>
> [1] https://github.com/dlang/dmd/pull/8591

Will have a look, thanks!

On Wednesday, 22 August 2018 at 17:58:15 UTC, Manu wrote:
> This is very topical for me just now... but no extern(C++)??
> I have some extern(C++) classes that need to have .h files generated
> for them. Is this a goal for the project?

Not if I can get away without it. I am rather opinionated against `extern(C++)` on principle and stand by the point it is not a suitable language for inter-language operations. Sorry, I know you have a very different opinion here :)

Actual production cases may end up requiring it anyway but I'll see how it goes.