Last weekend, I added formated comments to the definitions of pcb command
line options. The comments follow the syntax already in use for actions and
the file format. A typical option comment looks like this:
/--------------------------
/* %start-doc options Color-Options
@ftable @code
@item --black-color <string>
Color value for white. Default: @samp{#ffffff}
@end ftable
%end-doc
*/
COLOR (WhiteColor, "#ffffff", "white-color", "color value for white"),
\-------------------------
During build the script extract-doc compiles a file named options.texi .
Inside, all color options are assembled under the heading "Color-Options"
The result can be seen in the attached PDF.
I added an explaining line to every option and grouped them. In addition I
rewrote the top of the section to match the current behavior of pcb 1.99y.
There is a glitch and a catch. The glitch: The extract-doc script adds a new
node for every file it enters. Some general options sit not in main.c, but
in gui-top-window.c . Texi requires unique node names. That's why the
general options in gui-top-window.c are assembled under "Options." .
The catch: extract-doc sorts nodes according to the alphabet. In addition,
it can't deal with multi-word keys. This is why the bom options render first
and why all sections got one-word headings. Nevertheless, with documenting
comments the command line section of the manual almost automatically matches
the source. By contrast, the options in the command line section of
currently distributed manual are mostly obsolete since years.
---<)kaimartin(>---
--
Kai-Martin Knaak
Ãffentlicher PGP-SchlÃssel:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53Attachment:
pcb-commandline-options.pdf
Description: Adobe PDF document
_______________________________________________ geda-user mailing list geda-user@xxxxxxxxxxxxxx http://www.seul.org/cgi-bin/mailman/listinfo/geda-user