This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Doxygenate gdbtypes.h
- From: Stan Shebs <stanshebs at earthlink dot net>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 04 Mar 2014 11:51:03 -0800
- Subject: Re: [PATCH] Doxygenate gdbtypes.h
- Authentication-results: sourceware.org; auth=none
- References: <53151B5D dot 5000309 at earthlink dot net> <201403040039 dot s240db0w008027 at glazunov dot sibelius dot xs4all dot nl> <531529D4 dot 3050309 at earthlink dot net> <8761ntoogy dot fsf at gnu dot org> <53162394 dot 3030604 at earthlink dot net> <83txbdrd10 dot fsf at gnu dot org>
On 3/4/14 11:15 AM, Eli Zaretskii wrote:
>> Date: Tue, 04 Mar 2014 11:03:48 -0800
>> From: Stan Shebs <stanshebs@earthlink.net>
>>
>>> Just because some GNU packages use Doxygen (or CMake, or...) doesnât
>>> mean itâs a good idea; and it remains a GCS violation.
>>
>> Paragraph and sentence, please?
>
>>From the "GNU Manuals" node:
>
> The preferred document format for the GNU system is the Texinfo
> formatting language. Every GNU package should (ideally) have
> documentation in Texinfo both for reference and for learners. Texinfo
> makes it possible to produce a good quality formatted book, using TeX,
> and to generate an Info file. It is also possible to generate HTML
> output from Texinfo source. See the Texinfo manual, either the
> hardcopy, or the on-line version available through `info' or the Emacs
> Info subsystem (`C-h i').
>
> Nowadays some other formats such as Docbook and Sgmltexi can be
> converted automatically into Texinfo. It is ok to produce the Texinfo
> documentation by conversion this way, as long as it gives good results.
In this context, it's important that the standard says "preferred", not
"required". As we've been discussing since last August, writing
internals documentation as a separate manual in Texinfo has not worked
out for GDB. Fortunately, the general coding standards do allow
projects to set their own additional practices, where such changes
do not contradict any explicit requirements set down by the FSF.
Stan
stan@codesourcery.com