> Wait. Steven's comment was on the snarky side, but coming from a > long-time gcc contributor I don't think it was over the line or even > near it. I think he was expressing a perfectly valid point of view > considering the constraints that the FSF places on gcc developers. For > certain aspects of gcc, generating documentation from code makes all > kinds of sense. The fact that the FSF is preventing us from doing that > is a real problem. It's not a critical problem, but it's one in a line > of real problems.
Could part of the problem here be that RMS's view on "documentation" is that it's meant to be a creative process, somewhat akin to writing a book, and that mechanically creating "documentation" will produce something of much lower quality than what's done by hand? Back when he and I spoke regularly, I know that he cared a lot about the "literary" quality of the documentation and I think that part of this might be due to a "why would you want to do that anyway?" position on automaticaly-generated stuff. But we've heard that he indeed has no problem creating something that's in the form of documentation and calling it a "function index" or something similar. And I think we ought to seriously consider going in that direction, where there are two separate things: a MANUAL, written manually, which is meant to be high-quality language and is under the GFDL, and a separate document which is under the GPL and is generated automatically. This may also produce more of a split between the user and internal documentation. The user manual is the one that (I suspect), he's mostly concerned about that that needs to be produced manually to get appropriate quality. Then there's another GFDL'ed document that's an overview of the internals and references the third (GPL'ed) document that's automatically generated.
