Re: RFC: initial release of dtoh
On Fri, 24 Aug 2018 at 02:40, Walter Bright via Digitalmars-d-announce 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!
Re: RFC: initial release of dtoh
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.
Re: RFC: initial release of dtoh
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
Re: RFC: initial release of dtoh
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
Re: RFC: initial release of dtoh
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.
Re: RFC: initial release of dtoh
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.
Re: RFC: initial release of dtoh
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.
Re: RFC: initial release of dtoh
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
Re: RFC: initial release of dtoh
On Wed, 22 Aug 2018 at 04:05, Mihails via Digitalmars-d-announce 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?
Re: RFC: initial release of dtoh
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/drcekmxvfszpwifbu...@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"
Re: RFC: initial release of dtoh
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/drcekmxvfszpwifbu...@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?
Re: RFC: initial release of dtoh
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/drcekmxvfszpwifbu...@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.
Re: RFC: initial release of dtoh
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/drcekmxvfszpwifbu...@forum.dlang.org), but sadly it seems that no consensus has been reached.
RFC: initial release of dtoh
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.
