![]() System : Linux absol.cf 5.4.0-198-generic #218-Ubuntu SMP Fri Sep 27 20:18:53 UTC 2024 x86_64 User : www-data ( 33) PHP Version : 7.4.33 Disable Function : pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_get_handler,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,pcntl_async_signals,pcntl_unshare, Directory : /usr/share/doc/gnustep-base-doc/Base/ProgrammingManual/gs-base/ |
Upload File : |
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <!-- Created by GNU Texinfo 6.7, http://www.gnu.org/software/texinfo/ --> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>GSDoc (Objective-C GNUstep Base Programming Manual)</title> <meta name="description" content="GSDoc (Objective-C GNUstep Base Programming Manual)"> <meta name="keywords" content="GSDoc (Objective-C GNUstep Base Programming Manual)"> <meta name="resource-type" content="document"> <meta name="distribution" content="global"> <meta name="Generator" content="makeinfo"> <link href="index.html" rel="start" title="Top"> <link href="Make.html" rel="index" title="Make"> <link href="index.html#SEC_Contents" rel="contents" title="Table of Contents"> <link href="index.html" rel="up" title="Top"> <link href="Bundles-and-Frameworks.html" rel="next" title="Bundles and Frameworks"> <link href="Base-Library.html" rel="prev" title="Base Library"> <style type="text/css"> <!-- a.summary-letter {text-decoration: none} blockquote.indentedblock {margin-right: 0em} div.display {margin-left: 3.2em} div.example {margin-left: 3.2em} div.lisp {margin-left: 3.2em} kbd {font-style: oblique} pre.display {font-family: inherit} pre.format {font-family: inherit} pre.menu-comment {font-family: serif} pre.menu-preformatted {font-family: serif} span.nolinebreak {white-space: nowrap} span.roman {font-family: initial; font-weight: normal} span.sansserif {font-family: sans-serif; font-weight: normal} ul.no-bullet {list-style: none} --> </style> </head> <body lang="en"> <span id="GSDoc"></span><div class="header"> <p> Next: <a href="Bundles-and-Frameworks.html" accesskey="n" rel="next">Bundles and Frameworks</a>, Previous: <a href="Base-Library.html" accesskey="p" rel="prev">Base Library</a>, Up: <a href="index.html" accesskey="u" rel="up">Top</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Make.html" title="Index" rel="index">Index</a>]</p> </div> <hr> <span id="The-GNUstep-Documentation-System"></span><h2 class="appendix">Appendix A The GNUstep Documentation System</h2> <span id="index-gsdoc"></span> <p>GNUstep includes its own documentation system for producing HTML, PDF, and other readable documents for developers and users. (It also includes facilities for “Help” accessed within applications, but these are not covered here.) It is based on <i>GSdoc</i>, an XML language designed specifically for writing documentation for the <a href="http://www.gnustep.org">GNUstep project</a>. In practice, that means that it is designed for writing about software, and in particular, for writing about Objective-C classes. </p> <p>It may be used to write narrative documentation by hand, and it can also be autogenerated by the <i>autogsdoc</i> tool, which parses Objective-C source files and documents classes, methods, functions, macros, and variables found therein, picking up on special comments when provided to enhance the documentation. </p> <p>You can read more about GSdoc itself in this <a href="../../Tools/Reference/gsdoc.html">document</a>. </p> <p>The <i>autogsdoc</i> tool is described <a href="../../Tools/Reference/autogsdoc.html">here</a>. </p> <p>(Both of these documents are part of the <a href="../../Tools/Reference/index.html">Base Tools</a> documentation.) </p> <span id="Quick-Start"></span><h3 class="section">A.1 Quick Start</h3> <p>The basic approach to using GSdoc is this: when writing source code, put comments that begin with “<code>/**</code>” instead of the usual C “<code>/*</code>” in your <code>@interface</code> or <code>@implementation</code> file above class, variable, and method declarations. If you have any functions or macros you are making available put such comments in front of them too. The comments still end with the regular “<code>*/</code>”, no “<code>**/</code>” is necessary. </p> <div class="example"> <pre class="example">/** * The point class represents 2-d locations independently of any graphical * representation. */ @interface Point : NSObject { // instance variables ... } /** * New point at 0,0. */ + new; // ... /** * Return point's current X position. */ - (float) x; // ... @end </pre></div> <p>When you are finished, invoke <i>autogsdoc</i> giving it the names of all your header files. (It will find the implementation files automatically, as long as they have the same names; alternatively, give it the names of the implementation files as well.) This will produce a set of HTML files describing your classes. If you include the ’<code>-MakeFrames YES</code>’ argument, the HTML will be structured into frames for easy navigation. </p> <p>(Autogsdoc, like all GNUstep command line tools, is found in the ${GNUSTEP_SYSTEM_ROOT}/Tools directory.) </p> <p>You can also generate documentation automatically using the GNUstep make utility. Consult its primary <a href="../../Make/Manual/make_toc.html">documentation</a> for details. The short story is: </p> <div class="example"> <pre class="example">include $(GNUSTEP_MAKEFILES)/common.make DOCUMENT_NAME = MyProject MyProject_AGSDOC_FILES = <space-separated list of header files> MyProject_AGSDOC_FLAGS = <flags, like MakeFrames YES> include $(GNUSTEP_MAKEFILES)/documentation.make </pre></div> <p>Usually this is put into a separate makefile called “<code>DocMakeFile</code>” in the source directory. </p> <span id="Cross_002dReferencing"></span><h3 class="section">A.2 Cross-Referencing</h3> <p>GSdoc provides the ability to reference entities both within the project and in external projects. When writing GSdoc comments in source code, references are particularly easy to create. To refer to an argument of the method or function you are documenting, just type it normally; it will be presented in a special type face in the final documentation to show it is an argument. To refer to another method within the same class you are documenting, just type its selector with the + or - sign in front. This will be converted into a hyperlink in output forms that support that. To refer to another class, you just type the class’s name in [Brackets]. To refer to a method in another class, put the method selector after the name, as in [Class-methodWithArg1:andArg2:] (do not include a space). To refer to a protocol, use [(BracketsAndParentheses)] instead of just brackets. To refer to a category, use [Class(Category)]. For methods in these two cases, put the method name outside the parentheses. To refer to a function, simply type its name suffixed by parentheses(). </p> <span id="Comment-the-Interface-or-the-Implementation_003f"></span><h3 class="section">A.3 Comment the Interface or the Implementation?</h3> <p>Since <code>autogsdoc</code> picks up comments both from interface/header files and implementation/source files, you might be wondering where it is best to put them. There is no consensus on this issue. If you put them in the interface, then anyone you distribute your library to (with the headers but not the source) will be able to generate the documentation. The header file carries all of the specification for the class’s behavior. On the other hand, if you put the comments in the implementation, then people editing the source code will have the method descriptions handy when they need them. If <i>autogsdoc</i> finds comments for the same entity in both interface and implementation, they are concatenated in the result. </p> <p>Nonetheless, the recommendation of this author is that you put the comments in the header, since this is more within the spirit of Objective-C, where the interface file declares the behavior of a class. </p> <span id="Comparison-with-OS-X-Header-Doc-and-Java-JavaDoc"></span><h3 class="section">A.4 Comparison with OS X Header Doc and Java JavaDoc</h3> <p>The HTML output from all of these systems is roughly comparable. In terms of and comments needed in the source code to produce good class documentation, the GSdoc / autogsdoc system aims for maximal simplicity. In practice, requiring lots of special formatting makes developers less likely to document things, therefore, as described above, GSdoc does not require it, letting the parser do the work instead of the person. </p> <p>In terms of non-HTML output formats and control over the HTML format, these are not provided with GSdoc, yet, but there are plans to provide them through the use of XSLT as a presentation layer. </p> <hr> <div class="header"> <p> Next: <a href="Bundles-and-Frameworks.html" accesskey="n" rel="next">Bundles and Frameworks</a>, Previous: <a href="Base-Library.html" accesskey="p" rel="prev">Base Library</a>, Up: <a href="index.html" accesskey="u" rel="up">Top</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Make.html" title="Index" rel="index">Index</a>]</p> </div> </body> </html>