<p dir="ltr"><br>
On 11 Aug 2014 06:25, "Trent Forkert via D.gnu" <<a href="mailto:d.gnu@puremagic.com">d.gnu@puremagic.com</a>> wrote:<br>
><br>
> On Sun, Jul 27, 2014 at 12:25 PM, Iain Buclaw via D.gnu <<a href="mailto:d.gnu@puremagic.com">d.gnu@puremagic.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> Potential files up for deletion include:<br>
>><br>
>> - doc.c:  Because people should be using the (far) superior DDox [1].<br>
>> - macro.c: Used by the DDoc engine.<br>
>> - json.c: I can't think of a good reason to keep it.<br>
><br>
><br>
> 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.<br>

><br>
>  - Trent</p>
<p dir="ltr">Wasn't aware of that. Thanks for letting us know.</p>
<p dir="ltr">Have you actually tried using ddoc or json generation from gdc?  You are really better off using dmd for it.</p>
<p dir="ltr">These features are planned to be simplified in use anyway (no way of passing an out filename or directory path).</p>
<p dir="ltr"><a href="http://bugzilla.gdcproject.org/show_bug.cgi?id=119">http://bugzilla.gdcproject.org/show_bug.cgi?id=119</a><br></p>
<p dir="ltr">Iain.</p>