Improving ddoc

[Walter Bright via Digitalmars-d]

On 1/2/2015 4:29 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
> Now, full credit to the rust community: they were immediately friendly and
> helpful in advising me how to deal with this (you can pass a flag to the
> ./configure command to request not to build the docs).  And of course you can
> see this as primarily a fault in how the build system defines its targets and
> their dependencies.  But the simple fact is, had documentation generation been
> built in rather than relying on 3rd-party tools, it would never have been an
> issue, _and_ I'd have ended up having the documentation as well as just the
> compiler executable and libraries.

Note that Doxygen is a third party tool, it also requires a bunch more third 
party tools.

A friend of mine bemoaned using a piece of software on Linux that required not 
one but multiple different and specific versions of Perl be installed in order 
to even build the software.

Back in the early days of my compiler business, Microsoft shipped a linker on 
the DOS disks. So all my users had a linker. Unfortunately, the linker versions 
changed constantly. Eventually MS left the linker off of the DOS disks, but 
would include it on the disks of all sorts of other software they sold. The 
result was I couldn't rely on users having a linker, or any particular linker. 
There was a blizzard of MS linkers in the wild, each with their own features and 
bugs. It was a support nightmare, consuming more and more of my time. I had 
disks filled with my "linker collection" to test against.

Finally, I got my own linker (written by Bjorn Freeman-Benson). It wasn't the 
greatest linker evar, but it worked, it was consistent, I knew what users had, 
and I could fix bugs in it rather than find workarounds.

I learned over and over that controlling the full stack of what the user needed 
was very practical.