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.

Reply via email to