This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Documenting tools necessary for GCC [draft]
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- To: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 1 Jun 2003 16:13:49 +0100 (BST)
- Subject: Re: Documenting tools necessary for GCC [draft]
- References: <200305291727.NAA06347@caip.rutgers.edu><Pine.LNX.4.53.0305291835450.23254@kern.srcf.societies.cam.ac.uk><200305300040.UAA09131@caip.rutgers.edu> <Pine.LNX.4.53.0305301006030.31797@kern.srcf.societies.cam.ac.uk><200306011424.KAA11518@caip.rutgers.edu>
On Sun, 1 Jun 2003, Kaveh R. Ghazi wrote:
> I'm curious about this requirement, when making changes to the manual
> is there something that "make dvi" checks in terms of texi mistakes
> that "make info" wouldn't catch?
Anything in conditional sections that aren't used for info. (Problems
with conditional parts of manuals are more common with HTML output, so
perhaps "make html" which doesn't require extra tools should also be
included in the test procedures.) That paragraph in contribute.html was
mainly intended for changes to the manual that are solely manual changes,
not those incidental to a code change, though the additional testing of
those is good as well. Anything that only shows up ugly in printed output
(e.g., FOO_BAR_BAZ not inside @code or @samp - immediately obvious in the
printed output, not so in info). Overfull hboxes (e.g. missing @gol in
option summary lists, the need for which arises from differences in how
makeinfo and texinfo.tex handle macros).
--
Joseph S. Myers
jsm28@cam.ac.uk