www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - RFC: initial release of dtoh

reply Mihails <nope nope.nope> writes:
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.
Aug 22 2018
next sibling parent reply Seb <seb wilzba.ch> writes:
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.
Aug 22 2018
parent reply Mihails <nope nope.nope> writes:
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.
Aug 22 2018
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
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?
Aug 22 2018
next sibling parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
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"
Aug 22 2018
prev sibling parent Mihails <nope nope.nope> writes:
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.
Aug 22 2018
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
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?
Aug 22 2018
parent Mihails <nope nope.nope> writes:
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.
Aug 23 2018
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Aug 22 2018
parent Mihails <nope nope.nope> writes:
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!
Aug 23 2018
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/22/2018 4:01 AM, Mihails wrote:

 In my opinion, this functionality _should_ be part of 
 compiler itself, similar to .di generation.


This is not a bad idea.
Aug 24 2018
parent Manu <turkeyman gmail.com> writes:
On Fri, 24 Aug 2018 at 02:40, Walter Bright via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 On 8/22/2018 4:01 AM, Mihails wrote:

 In my opinion, this functionality _should_ be part of
 compiler itself, similar to .di generation.


 This is not a bad idea.


This, please!
Aug 26 2018
prev sibling parent reply Uknown <sireeshkodali1 gmail.com> writes:
On Wednesday, 22 August 2018 at 11:01:02 UTC, 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).
 [...]


This is all very nice. I agree that this kind of thing should be 
a part of the compiler, but I think it should be a compiler 
plugin. If dmd had compiler plugins, I think stuff like this and 
`dpp` would be much nicer to use.
Aug 24 2018
next sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
On Friday, 24 August 2018 at 10:09:07 UTC, Uknown wrote:


 This is all very nice. I agree that this kind of thing should 
 be a part of the compiler, but I think it should be a compiler 
 plugin. If dmd had compiler plugins, I think stuff like this 
 and `dpp` would be much nicer to use.


I agree.  We also need compiler plugins for things like this: 
https://github.com/dlang/dmd/pull/6961

Mike
Aug 24 2018
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2018-08-24 12:09, Uknown wrote:


 This is all very nice. I agree that this kind of thing should be a part 
 of the compiler, but I think it should be a compiler plugin. If dmd had 
 compiler plugins, I think stuff like this and `dpp` would be much nicer 
 to use.


We have the front end available as a library, but not support for plugins.

-- 
/Jacob Carlborg
Aug 25 2018
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 26/08/2018 7:08 AM, Jacob Carlborg wrote:

 On 2018-08-24 12:09, Uknown wrote:
 

 This is all very nice. I agree that this kind of thing should be a 
 part of the compiler, but I think it should be a compiler plugin. If 
 dmd had compiler plugins, I think stuff like this and `dpp` would be 
 much nicer to use.


 
 We have the front end available as a library, but not support for plugins.


Even though it is available, you won't be using it.

Between memory leaks and not-reusable, it aren't an option.
Aug 25 2018