Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
July 27, 2014 [Projects] Review of GDC frontend components for 2.066 merge. | ||||
---|---|---|---|---|
| ||||
Hi, I've been turning around the idea in my head to start removing aspects of the D frontend from GDC as each part is converted into the more modular/pluggable Visitor interface. Some initial thoughts are along the lines of, remove the extraneous tooling components that we have on offer in DMD, meaning GDC is strictly kept as a compiler only. Potential files up for deletion include: - doc.c: Because people should be using the (far) superior DDox [1]. - macro.c: Used by the DDoc engine. - json.c: I can't think of a good reason to keep it. [1] https://github.com/rejectedsoftware/ddox Others projects in the flux for 2.066 include: - Renaming main glue source files under a clean naming scheme. - Re-write glue components against the Visitor interface. - Move druntime library functions to a .def macro file. - Move/Fork C++ mangling (cppmangle.c) into GDC's glue. - Update for GCC C++ coding conventions. - Document! Document! Document! Regards Iain. |
August 11, 2014 Re: [Projects] Review of GDC frontend components for 2.066 merge. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw Attachments:
| On Sun, Jul 27, 2014 at 12:25 PM, Iain Buclaw via D.gnu <d.gnu@puremagic.com > wrote: > Hi, > > I've been turning around the idea in my head to start removing aspects of the D frontend from GDC as each part is converted into the more modular/pluggable Visitor interface. > > Some initial thoughts are along the lines of, remove the extraneous tooling components that we have on offer in DMD, meaning GDC is strictly kept as a compiler only. > > Potential files up for deletion include: > > - doc.c: Because people should be using the (far) superior DDox [1]. > - macro.c: Used by the DDoc engine. > - json.c: I can't think of a good reason to keep it. > I don't think getting rid of DDoc is a good idea (having it built into the compiler is a plus, IMO), and I should probably point out that according to DDox documentation, you need the compiler-generated JSON to actually do anything. So at least one of these systems needs to stick around if GDC is to generate documentation without depending on DMD or LDC. - Trent |
August 11, 2014 Re: [Projects] Review of GDC frontend components for 2.066 merge. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw Attachments: | On Sun, 27 Jul 2014 16:25:40 +0000
"Iain Buclaw via D.gnu" <d.gnu@puremagic.com> wrote:
> Potential files up for deletion include:
> - doc.c: Because people should be using the (far) superior DDox
> [1].
oh, no, please leave docs module! that was the thing that helps me to actually write documentation for my code. i'll never do that again if i'll need to use some external tool for doc generation.
it's like removing unittest feature, 'cause... oh, well, there are alot
of unit-testing libraries and tools, right? no. D is the only language
where i actually writing unittests and keeping 'em up-to-date.
exactly for the same reason i'm doing this with docs: i need no external
tools to use this features.
|
August 11, 2014 Re: [Projects] Review of GDC frontend components for 2.066 merge. | ||||
---|---|---|---|---|
| ||||
Attachments:
| On 11 Aug 2014 06:25, "Trent Forkert via D.gnu" <d.gnu@puremagic.com> wrote: > > On Sun, Jul 27, 2014 at 12:25 PM, Iain Buclaw via D.gnu < d.gnu@puremagic.com> wrote: >> >> Hi, >> >> I've been turning around the idea in my head to start removing aspects of the D frontend from GDC as each part is converted into the more modular/pluggable Visitor interface. >> >> Some initial thoughts are along the lines of, remove the extraneous tooling components that we have on offer in DMD, meaning GDC is strictly kept as a compiler only. >> >> Potential files up for deletion include: >> >> - doc.c: Because people should be using the (far) superior DDox [1]. >> - macro.c: Used by the DDoc engine. >> - json.c: I can't think of a good reason to keep it. > > > I don't think getting rid of DDoc is a good idea (having it built into the compiler is a plus, IMO), and I should probably point out that according to DDox documentation, you need the compiler-generated JSON to actually do anything. So at least one of these systems needs to stick around if GDC is to generate documentation without depending on DMD or LDC. > > - Trent Wasn't aware of that. Thanks for letting us know. Have you actually tried using ddoc or json generation from gdc? You are really better off using dmd for it. These features are planned to be simplified in use anyway (no way of passing an out filename or directory path). http://bugzilla.gdcproject.org/show_bug.cgi?id=119 Iain. |
August 11, 2014 Re: [Projects] Review of GDC frontend components for 2.066 merge. | ||||
---|---|---|---|---|
| ||||
Attachments:
| On Mon, Aug 11, 2014 at 4:29 AM, Iain Buclaw via D.gnu <d.gnu@puremagic.com> wrote: > > On 11 Aug 2014 06:25, "Trent Forkert via D.gnu" <d.gnu@puremagic.com> wrote: > > > > On Sun, Jul 27, 2014 at 12:25 PM, Iain Buclaw via D.gnu < > d.gnu@puremagic.com> wrote: > >> > >> Hi, > >> > >> I've been turning around the idea in my head to start removing aspects > of the D frontend from GDC as each part is converted into the more modular/pluggable Visitor interface. > >> > >> Some initial thoughts are along the lines of, remove the extraneous > tooling components that we have on offer in DMD, meaning GDC is strictly kept as a compiler only. > >> > >> Potential files up for deletion include: > >> > >> - doc.c: Because people should be using the (far) superior DDox [1]. > >> - macro.c: Used by the DDoc engine. > >> - json.c: I can't think of a good reason to keep it. > > > > > > I don't think getting rid of DDoc is a good idea (having it built into > the compiler is a plus, IMO), and I should probably point out that according to DDox documentation, you need the compiler-generated JSON to actually do anything. So at least one of these systems needs to stick around if GDC is to generate documentation without depending on DMD or LDC. > > > > - Trent > > Wasn't aware of that. Thanks for letting us know. > > Have you actually tried using ddoc or json generation from gdc? You are really better off using dmd for it. > > Nothing beyond simple test cases for my experimental CMake work, where I'm trying to have the same support for dmd, ldc, and gdc. From everything I've tried, ddoc generation works the same as dmd/ldc. I don't need/use json generation, though. > These features are planned to be simplified in use anyway (no way of passing an out filename or directory path). > > http://bugzilla.gdcproject.org/show_bug.cgi?id=119 > > Iain. > I'm mostly supportive of those changes (cleaner interfaces are nice). The only thing I see is that I'm not sure how often a user would actually want docs and interfaces to be written to the same directory as the -o file, instead of docs/ and import/ directories. Requiring files be copied/moved into place after the fact is workable for me, if a little awkward. - Trent |
Copyright © 1999-2021 by the D Language Foundation