Drop ddoc from compiler

[andrey-zherikov]

Compiler should compile, not do anything else. Hence compiler should not support generation of documentation and corresponding CLI options should be removed.
On another side, there can be separate tool that generates documentation from ddoc comments. Although I prefer dropping ddoc completely in favor of other documentation tools (like doxygen) that support multiple languages and are more widely spreaded.

[adamdruppe]

What I had in mind was making opend -D load up adrdox instead. Like I said in the blog, ddoc was one of the first bigger things I tried to fix that got stonewalled (I'm actually still I think the 6th most contributor to upstream ddoc even with just the little things I got in).

adrdox is roughly compatible with ddoc for existing code but it is very D specific...

[andrey-zherikov]

Why can't there be openddox tool?

[andrey-zherikov]

My point is "do one thing and do it well":

• Compiler compiles source code into executable code.
• Doc generator converts source code into documentation.
• Linter does code linting.
• Analyzer analyzes code.
• etc

[quickfur]

In an ideal world, the compiler would be a library, and the (external-facing) compiler would just be a front-end to this library. The doc generator would also be a front-end that uses the library to extract doc comments and do its thing. Ditto with linter, analyzer, etc.. Why a library? So that the various frontends are guaranteed to be always in sync with each other. I.e., you won't get into the situation where something compiles but fails the linter, or the doc generator parses the input differently from the compiler.

The current codebase is a long way from being a library, though. 90%, maybe even 95% of dmd assumes a single-shot batch mode compilation process, and a huge chunk of the code was written from this perspective -- allocate and forget is the modus operandi, for example. Upstream has been trying to turn it into a library for a long time now, but progress is slow because it goes directly against how the code was originally written. I'm aware that dmd-as-a-library has been a thing for a while now, but the API is less than ideal: after compiling once you pretty much have to unload and reload the entire library just to get a clean slate again. It's definitely not at the point where you can compile multiple times or compile small snippets from different threads without the compiler instances stomping all over each other.

So for the time being, the best we can do is to split off bits and pieces of dmd and delegate it to an external tool, like replacing ddoc with adrdox.

[adamdruppe]

My idea for the opend command line program is that it does that kind of delegation to other pieces. dmd is its "compile quick" driver. ldc is its "compile optimized" driver. adrdox is its "generate documentation website" driver, stuff like that.

[quickfur]

Nice, I think that would be cool.

[andrey-zherikov]

My idea for the opend command line program is that it does that kind of delegation to other pieces. dmd is its "compile quick" driver. ldc is its "compile optimized" driver. adrdox is its "generate documentation website" driver, stuff like that.

This ideally matches subcommands: opend build, opend docgen, opend lint etc...
We can add any subcommand later without interfering with existing ones and having a headache like "we can't use -I option because it's already used in build command"