|
ROBODoc 3.2.2 ManualUpdated July 2000 ROBODoc is a documentation tool for C, C++, Java, Assembler, Basic, Fortran, LaTeX, Postscript, Tcl/Tk, LISP, Forth, Perl, Shell Scripts, Occam, COBOL, HTML and many other languages. Additional languages can be supported by a few modifications to the source code. Copyright (C) 1994-2000 Frans Slothouber and Jacco van Weert. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA 1 Credits
2 Table of Contents01......... Credits02......... Table of Contents 03......... Introduction 04......... Hardware and software requirements 05......... Goals and Limitations 06......... How to Format Your Code for use with ROBODoc 06.01.......... Header Names 06.02.......... Header Types 06.03.......... Begin Marker 06.04.......... Remark Marker 06.05.......... End Marker 06.06.......... Header Items 06.07.......... Item Name Limitations 06.08.......... Source Item 07......... Creating Cross Links 07.01.......... Limitations 08......... Master Index File 08.01.......... examples 09......... Automation with make 10......... What to do if You have Sources in Multiple Directories 11......... The ROBODoc Defaults File 12......... ROBODoc Command Line Options 13......... Adding New Languages 14......... Suggestions and Bugs 3 IntroductionROBODoc is based on the AutoDocs program written some time ago by Commodore. The idea is to include for every function a standard header containing all sorts of information about that procedure/function. An AutoDocs program extracts these headers from the source file and puts them in an autodocs file. This allows you to include the program documentation in the source code and makes it unnecessary to maintain two documents. ROBODoc is such a program, however ROBODoc has several additions. For one it can generate the documentation in different formats, ASCII, HTML, RTF, LaTeX, and AmigaGuide. Another feature is that it automatically creates links within the document, and to other documents. It is also possible to include parts of the source in you documentation, complete with links. For instance it is possible to include the complete source code of a function, and have the function names in the source point to their documentation. Besides documenting functions, you can also document classes, methods, structures, variables, and constants. If you never have used AutoDoc or ROBODoc before you might take a look at the example in the Source/. Run the command: make xhtml make example This creates the ROBODoc documentation for the ROBODoc program itself and then starts netscape to view the documentation. Also have a look at the source files, they illustrates the use of headers. ROBODoc can generate documentation in five different formats:
4 Hardware and software requirementsROBODoc was developed in 1994 on a standard Amiga 1200, a system with a 20MHz 68020 processor and 2 Mbyte of RAM. It should therefore be no problem to run it on any of the currently available systems :) The complete source code consists of a series of file that can be found in the Source directory. It is written according (hopefully) to the ANSI C standard and uses no special functions, so it should run on every system with an ANSI C-compiler. 5 Goals and LimitationsROBODoc is intended for small to medium sized projects that have a relatively flat structure and especially projects that use a mix of different programming languages. ROBODoc was designed to be easy to use and to work with a lot of different programming languages. It has no knowledge of the syntax of a programming languages. It just some knowledge about how remarks start and end in some programming languages. This means that you sometimes have to do a little more work compared to other tools that have detailed knowledge of the syntax of a particular language. They can use that knowledge to figure out some of the information automatically. This usually also means that they work only with one or two languages. ROBODoc operates on one file at a time. It has no mechanism to process whole sets of source files. Makefiles should be used for this. How to do this is explained in this document with various example makefiles. Have a look at them. ROBODoc can work with projects where the source code is located in different subdirectories. However the generated documentation is expected to go into one single directory. 6 How to Format Your Code for use with ROBODocROBODoc allows you to mix the program documentation with the source code. It does require though that this documentation has a particular layout so ROBODoc can recognize it. The following header was taken from the original ROBODoc program (many versions back).
You would place this headers in front of functions, classes, methods, structure definitions, or any of the major components in your program. The header itself contains a number of items that provide structured information about the component. There are a number of special markers in a header (indicated in red above). There are two special markers that mark the begin and end of a header. Each line in a header should start with a remark marker. The starts of each item is marked by an Item Name (in all capitals). 6.1 Header NamesROBODoc makes some assumptions about the structure a project. It assumes that a project consists of a number of modules, and that each module consists of a number of components. These components can be anything that you care to document; functions, variables, structures, classes, methods etc. Projects, modules, and components all have names. The names allow ROBODoc to structure the documentation and create cross-links. Names are defined in the header name. It is either of the form <project name>/<module name> for a module header, or of the form <module name>/<component name> for all other headers. 6.2 Header TypesYou can provide ROBODoc with some additional information by specifying the header type. The header type tells ROBODoc what kind of component you are documenting. This information allows ROBODoc to create more useful index tables. The type is identified by a single character, as listed in the following table
Internal headers are special. They can be used to hide certain headers. They are only extracted if requested. You could use to document internal functions that you do now want clients to see. 6.3 Begin MarkerThe beginning of a header is marked with a special marker. The above header is intended for a program in C. In other programming languages the marker looks slightly different, since each language has its own convention for starting remarks. ROBODoc recognizes the following begin markers:
After these initial four asterisks, there is the character to identify the kind of header, then another asterisks, and then header name. After this you can specify a version number surrounded by "[]". The version number is stored but not used for anything at the moment. All characters after that are ignored. This might sound terribly complicated, it is not. Here are some examples: A header for a module called analyser in a project called ChessMaster for C, is has version number 1.0 /****h* ChessMaster/analyser [1.0] * In Assembler, a function header, for the function init() in the module finance.library: ****f* finance.library/init * In C++, a class header for class Puppet, for the module puppetmaster, version v2.12 /****c* puppetMaster/Puppet [v2.12] ****** For the same class a method called Puppet::Talk /****m* puppetMaster/Puppet::Talk [v2.12] ****** A project header, in Fortran C ****h* ChessMaster/analyser C In Basic REM ****h* ChessMaster/analyser 6.4 Remark MarkerEach line in the body of a header should start with a remark marker. This marker is stripped from the line and the remaining part is used to generated the documentation. The following markers are recognized by ROBODoc.
6.5 End MarkerA header ends with an end marker. An end marker is a remark marker followed by three asterisks. ROBODoc recognizes following strings as end markers:
6.6 Header ItemsWhen ROBODoc has found a header it will try to identify the items in this header. It does this by looking for the item name. The following item names are currently supported:
ROBODoc does this so that it can format each item with a different style (colour, font, etc.) if the user want it. These can be specified in the robodoc.defaults file, see the next section more information. 6.7 Item Name LimitationsIf you happen to have a function which name is in all uppercase, this sometimes conflicts with where ROBODoc thinks an item name starts and where the item body starts. Bernhard Roessmann suggest the following workaround: Example header producing this error: /***** basic.c/RETURN * NAME * RETURN : Return from subroutine * SYNOPSIS * RETURN * FUNCTION * Return from subroutine ******/ Here the item name "FUNCTION" will be interpreted as ordinary text, not as an item name. Workaround: Add an empty line: /***** basic.c/RETURN * NAME * RETURN : Return from subroutine * SYNOPSIS * RETURN * * FUNCTION * Return from subroutine ******/ 6.8 Source ItemThe source item allows you to include part of the source in the documentation as is demonstrated by the following example.
This would create the following documentation
7 Creating Cross LinksCreating hyper links within a document and across documents is the most interesting feature of ROBODoc. A document with such links is much more easier to read. If your source code consists of just one file, creating links is easy. Just tell ROBODoc that you want to have the output in HTML or AmigaGuide format, and it will automatically generate the links. That is, at the beginning of the document it will create a table of contents that consists of links to all your function headers. ROBODoc will also search the complete text of you documentation for reference to function names, and it will create a link to the documentation of that function. In most cases, however, your source code does not consists of a single file. It is also possible, however, to create links to other files. This does require the use of some additional files, called xref files. These files can be generated with ROBODoc. These files contain information about in which file and where in the file references can be found. Lets assume your project is split up in five different source files, and you want to generate links between these five files. What you have to do to accomplish this is to create a xref file for each of those five files. With the GENXREF option ROBODoc will generate such a xref file from the a source-file. When you use this option, only the xref file is created not the autodocs-file, however you still have to specify the name of the autodocs file because this name is needed for the creation of the xref file. When all xref files are created you are ready to create the documentation. To do so you use ROBODOC with the XREF option. It needs a parameter which is the name of the file in which the names of all xref files are defined. Notice: this is a file with file names, it has to be created it by hand. An example will make things more clear. In the ROBODoc archive, under examples/C there are two source files prog1.c and prog2.c. We can create documentation with hyper links from these two files as follows: First create the xref files:
Now there are two xref files: prog1.c.xref and prog2.c.xref. Note that ROBODoc did not create any HTML files, just the xref files. The name prog1.c.html is needed to create the correct xref files. For prog1.c internal headers were also included. Now create a file with the xref file names. This file will hold only two lines. You can give it any name, say xref_files.
Now generate the final documentation:
Have a look the the documentation generated: 7.1 LimitationsROBODoc knows very little about the grammar of programming languages. Links are created by looking up words in a table. This means that it sometimes creates links where there should be none. For instance if you have a function called usage(); every time you use the word usage in any of your documentation a link will show up. It also means that sometimes is does not create links where you would like it to create a link. Say you include the source code of a method using the source item. Your method uses other methods of the class. You would like to have links pointing to the documentation of these methods each time you use one. They will not appear though. Since to ROBODoc stores the whole name of a method, ie, someClass::MethodName. In the method source you will use just MethodName(). 8 Master Index FileIf your project consists of many source files you might want to create a master index file. For HTML output this file contains links to the documentation generated from each of your source files as well as a list of all "objects" that you documented. All "objects" are listed according to header type, using the following order: Projects, Classes, Methods, Stuctures, Functions, Variables, Constants, Generic, Internal. For LaTeX output this file is one big document that contains the documentation generated from all your source files. It also includes a table of contents and an index section. This index lists the page number of the page a function's documentation. This index file is generated based on the information found in your xrefs file. That is the file with the names of all your xref files. So before you can create the master index file you have to create all your xref files. To generate a master index file use: robodoc <xrefs file> <master index file> INDEX HTML TITLE "Master Index" or robodoc <xrefs file> <master index file> INDEX LATEX TITLE "ROBODoc API Documentation" The master index file can currently only be generated in HTML or LaTeX. If you use if for LaTeX documentation you need to use the option SINGLEDOC when you generate the documentation from your various source files. This ensures that no document preambles are generated. The master index file contains command that includes all your documentation files and make it into one single document. 8.1 examplesHere are some examples of master index files
9 Automation with makeThe whole process of creating documentation with ROBODoc is of course best automated with make. Have a look at the following makefile.
It includes all the necessary commands to generate and view the documentation for you project. You create documentation in any of the four formats. For instance to create documentation in html format use:
To make documentation in LaTeX format use:
To view your documentation use:
or
To clean up all the documentation files use: make clean To use this make file in project set the variable SOURCE to the names of your source files and set the variable PROJECT to the name of your project. You can find a copy of the above makefile Docs/example_makefile. This should get you started in no time. 10 What to do if You have Sources in Multiple DirectoriesIt is possible to have your sources in multiple subdirectories. However the generated documentation is expected to be in one single directory. If not the cross references will be wrong, at least in the HTML documentation. Say you have the following directory structure:
You can create the documentation for that as follows (assuming you are in Project):
This generates the following files:
With some version of make (for instance the gnu version) you can strip the directory part of a filename with $(notdir NAME) How this can be used is shown in the following example makefile. Here we have the sources for robodoc, the .c files are in the directory Sources/ and .h files are in the directory Headers/.
11 The ROBODoc Defaults FileThe robodoc.default file can be used to change the appearance of the documentation. For each item type you can define how the corresponding text should be rendered. Each line in the default file consists of two parts, the item type and the item attributes. For instance AUTHOR LARGE ITALICS BOLD UNDERLINE Specifies that the AUTHOR item has the attributes LARGE, ITALICS, BOLD, and UNDERLINE. The effect of each attribute is listed in the following table.
12 ROBODoc Command Line OptionsWhen using ROBODoc you should provide at least two parameters robodoc <source file> <documentation file> [options] Here sourcefile is the file with the program source from which the documentation is to be extracted. The documentation file is the file that will contain the extracted documentation. In case you are creating a master index file you have to specify three parameters robodoc <xrefs file> <master index file> INDEX [options] In addition to this you can specify one or more of the following options:
If you wonder why all the odd ALL CAPS flags are used instead of for instance "-x"; this was how it was done on the Amiga. The following abbreviations are also allowed:
13 Adding New LanguagesTo add a new programming language to ROBODoc you have to edit headers.c. Here you find three variables: header_markers, remark_markers, and end_markers. There are all arrays, and you have to add an new entry to each of these three arrays. Say your programming language uses the following type of remarks: $%% This is a remark with some text and some more and some more %%$ That is is starts with three spaces and then $%%, and has to end with %%$. Then you would add to header_markers " $%%****", To remark_markers you would add " *", And to end_markers you would add " $%%***", You can then use the following kind of headers in your program: $%%****f* Test/afunction ***** * NAME * afunction * FUNCTION * A test. * SOURCE *%%$ afunction(test,test) [ print hello world ; ] $%%***%%$ 14 Suggestions and BugsIf you find any bugs, catch them, put them in a jar, and send them to: fslothouber@acm.orgSuggestions are also welcome at this address. Flames can be directed to the sun. |