mirror of
https://git.rtems.org/rtems-docs/
synced 2025-05-15 17:26:42 +08:00
eng/coding-doxygen: Fix errors
This work was part of GCI 2018.
This commit is contained in:
parent
b8b4f14973
commit
cc826d74f3
@ -4,10 +4,10 @@
|
|||||||
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
|
.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
|
||||||
|
|
||||||
General Doxygen Recommentations
|
General Doxygen Recommentations
|
||||||
-------------------------------
|
===============================
|
||||||
|
|
||||||
TBD - Convert the following to Rest and insert into this file
|
.. COMMENT: TBD - Convert the following to Rest and insert into this file
|
||||||
TBD - https://devel.rtems.org/wiki/Developer/Coding/Doxygen
|
.. COMMENT: TBD - https://devel.rtems.org/wiki/Developer/Coding/Doxygen
|
||||||
|
|
||||||
.. sidebar:: *History*
|
.. sidebar:: *History*
|
||||||
|
|
||||||
@ -23,41 +23,44 @@ TBD - https://devel.rtems.org/wiki/Developer/Coding/Doxygen
|
|||||||
diagrams.
|
diagrams.
|
||||||
|
|
||||||
Doxygen Best Practices
|
Doxygen Best Practices
|
||||||
^^^^^^^^^^^^^^^^^^^^^^
|
----------------------
|
||||||
|
|
||||||
* Do not use @a. Instead use @param to document function parameters.
|
* Do not use ``@a``. Instead use ``@param`` to document function parameters.
|
||||||
* Do not use @return. Instead use @retval to document return status codes.
|
* Do not use ``@return``. Instead use ``@retval`` to document return status
|
||||||
|
codes.
|
||||||
* Do not write documentation for trivial functions.
|
* Do not write documentation for trivial functions.
|
||||||
* Do not repeat documentation, use @see for example.
|
* Do not repeat documentation, use ``@see`` for example.
|
||||||
* Do not use @note.
|
* Do not use ``@note``.
|
||||||
* Use groups and arrange them in a hierarchy. Put every file into at least one group.
|
* Use groups and arrange them in a hierarchy. Put every file into at least
|
||||||
|
one group.
|
||||||
* Use dot comments for state diagrams.
|
* Use dot comments for state diagrams.
|
||||||
* Use one whitespace character after an asterisk.
|
* Use one whitespace character after an asterisk.
|
||||||
|
|
||||||
Special Notes for Google Code In Students
|
Special Notes for Google Code-in Students
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
-----------------------------------------
|
||||||
|
|
||||||
* Follow the directions given by the `Google Code In
|
Follow the directions given by the `Google Code-in
|
||||||
<https://devel.rtems.org/wiki/GCI>`_ task and this should take care
|
<https://devel.rtems.org/wiki/GCI>`_ task and this should take
|
||||||
of itself if in doubt ask a mentor and/or tell a mentor the decision
|
care of itself if in doubt ask a mentor and/or tell a mentor the decision you
|
||||||
you made.
|
made.
|
||||||
|
|
||||||
Header File Example
|
Header File Example
|
||||||
^^^^^^^^^^^^^^^^^^^
|
-------------------
|
||||||
|
|
||||||
The files *thread.h*
|
`thread.h
|
||||||
(https://git.rtems.org/rtems/tree/cpukit/score/include/rtems/score/thread.h)
|
<https://git.rtems.org/rtems/tree/cpukit/include/rtems/score/thread.h>`_ and
|
||||||
and *threadimpl.h*
|
`threadimpl.h
|
||||||
(https://git.rtems.org/rtems/tree/cpukit/score/include/rtems/score/threadimpl.h)
|
<https://git.rtems.org/rtems/tree/cpukit/include/rtems/score/threadimpl.h>`_
|
||||||
should be a good example of how a header file should be written. The
|
should be a good example of how a header file shouldbe written. The following
|
||||||
following gives details in bits and pieces.
|
gives details in bits and pieces.
|
||||||
|
|
||||||
Header blocks
|
Header blocks
|
||||||
^^^^^^^^^^^^^
|
-------------
|
||||||
|
|
||||||
Header files should contain the similar comment blocks as other source files, described at `Boilerplate File Header <https://devel.rtems.org/wiki/Developer/Coding/Boilerplate_File_Header>`_.
|
Header files should contain the similar comment blocks as other source files,
|
||||||
|
described at :ref:`coding-file-hdr`.
|
||||||
|
|
||||||
.. code-block:: c
|
.. code-block:: c
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* @file
|
* @file
|
||||||
@ -75,25 +78,24 @@ Header files should contain the similar comment blocks as other source files, de
|
|||||||
* http://www.rtems.com/license/LICENSE.
|
* http://www.rtems.com/license/LICENSE.
|
||||||
*/
|
*/
|
||||||
|
|
||||||
Header Guard
|
Header guard
|
||||||
^^^^^^^^^^^^
|
------------
|
||||||
|
|
||||||
After the comment blocks, use a header guard that assembles at
|
After the comment blocks, use a header guard that assembles at least the
|
||||||
least the include path of the file. For example, if flipflop.h is in
|
include path of the file. For example, if ``flipflop.h`` is in
|
||||||
<rtems/lib/flipflop.h> then
|
``<rtems/lib/flipflop.h>`` then
|
||||||
|
|
||||||
.. code-block:: c
|
.. code-block:: c
|
||||||
|
|
||||||
#ifndef RTEMS_LIB_FLIP_FLOP_H
|
#ifndef RTEMS_LIB_FLIP_FLOP_H
|
||||||
#define RTEMS_LIB_FLIP_FLOP_H
|
#define RTEMS_LIB_FLIP_FLOP_H
|
||||||
|
|
||||||
Includes
|
Includes
|
||||||
^^^^^^^^
|
--------
|
||||||
|
|
||||||
Then add your include files before protecting C declarations from C++.
|
Then add your include files before protecting C declarations from C++.
|
||||||
|
|
||||||
|
.. code-block:: c
|
||||||
.. code-block:: c
|
|
||||||
|
|
||||||
#include <rtems.h>
|
#include <rtems.h>
|
||||||
|
|
||||||
@ -102,14 +104,13 @@ Then add your include files before protecting C declarations from C++.
|
|||||||
#endif /* __cplusplus */
|
#endif /* __cplusplus */
|
||||||
|
|
||||||
Using @defgroup for group definitions
|
Using @defgroup for group definitions
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
-------------------------------------
|
||||||
|
|
||||||
Add any group definitions surrounding the function declarations
|
Add any group definitions surrounding the function declarations that belong
|
||||||
that belong in that group. Rarely, a header may define more than one
|
in that group. Rarely, a header may define more than one group. Here we use
|
||||||
group. Here we use a dot diagram.
|
a dot diagram.
|
||||||
|
|
||||||
|
.. code-block:: c
|
||||||
.. code-block:: c
|
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* @defgroup FlipFlop Flip-Flop
|
* @defgroup FlipFlop Flip-Flop
|
||||||
@ -136,13 +137,12 @@ group. Here we use a dot diagram.
|
|||||||
*/
|
*/
|
||||||
|
|
||||||
enum and struct
|
enum and struct
|
||||||
^^^^^^^^^^^^^^^
|
---------------
|
||||||
|
|
||||||
Provide documentation for declarations of enumerated types and
|
Provide documentation for declarations of enumerated types and structs.
|
||||||
structs. Use typedefs for structs, and do not use _t as a typename suffix.
|
Use typedefs for structs, and do not use ``_t`` as a typename suffix.
|
||||||
|
|
||||||
|
.. code-block:: c
|
||||||
.. code-block:: c
|
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* @brief The set of possible flip-flop states.
|
* @brief The set of possible flip-flop states.
|
||||||
@ -171,15 +171,14 @@ structs. Use typedefs for structs, and do not use _t as a typename suffix.
|
|||||||
flip_flop_state secondary;
|
flip_flop_state secondary;
|
||||||
} flip_flop_multiple;
|
} flip_flop_multiple;
|
||||||
|
|
||||||
|
|
||||||
Using @name for organization
|
Using @name for organization
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
----------------------------
|
||||||
|
|
||||||
Complicated groups can be given additional organization by using @name,
|
Complicated groups can be given additional organization by using ``@name``, or
|
||||||
or by declaring additional groups within the hierarchy of the header
|
by declaring additional groups within the hierarchy of the header file's
|
||||||
file's top-level group.
|
top-level group.
|
||||||
|
|
||||||
.. code-block:: c
|
.. code-block:: c
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* @name Flip-Flop Maintenance
|
* @name Flip-Flop Maintenance
|
||||||
@ -188,14 +187,13 @@ file's top-level group.
|
|||||||
*/
|
*/
|
||||||
|
|
||||||
Declaring functions
|
Declaring functions
|
||||||
^^^^^^^^^^^^^^^^^^^
|
-------------------
|
||||||
|
|
||||||
Function declarations should have an @brief that states what the function
|
Function declarations should have an @brief that states what the function does
|
||||||
does in a single topic sentence starting with a descriptive verb in the
|
in a single topic sentence starting with a descriptive verb in the present
|
||||||
present tense.
|
tense.
|
||||||
|
|
||||||
|
.. code-block:: c
|
||||||
.. code-block:: c
|
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* @brief Initializes the flip-flop state.
|
* @brief Initializes the flip-flop state.
|
||||||
@ -217,13 +215,13 @@ present tense.
|
|||||||
|
|
||||||
Do not document trivial functions, such as getter/setter methods.
|
Do not document trivial functions, such as getter/setter methods.
|
||||||
|
|
||||||
.. code-block:: c
|
.. code-block:: c
|
||||||
|
|
||||||
flip_flop_state flip_flop_current_state(void);
|
flip_flop_state flip_flop_current_state(void);
|
||||||
|
|
||||||
Close the documentation name definition and open a new name definition.
|
Close the documentation name definition and open a new name definition.
|
||||||
|
|
||||||
.. code-block:: c
|
.. code-block:: c
|
||||||
|
|
||||||
/** @} */
|
/** @} */
|
||||||
|
|
||||||
@ -252,12 +250,12 @@ Close the documentation name definition and open a new name definition.
|
|||||||
/** @} */
|
/** @} */
|
||||||
|
|
||||||
Ending the file
|
Ending the file
|
||||||
^^^^^^^^^^^^^^^
|
---------------
|
||||||
|
|
||||||
Close the documentation group definition, then the extern C declarations,
|
Close the documentation group definition, then the extern C declarations,
|
||||||
then the header guard.
|
then the header guard.
|
||||||
|
|
||||||
.. code-block:: c
|
.. code-block:: c
|
||||||
|
|
||||||
/** @} */
|
/** @} */
|
||||||
|
|
||||||
@ -267,12 +265,12 @@ then the header guard.
|
|||||||
|
|
||||||
#endif /* RTEMS_LIB_FLIP_FLOP_H */
|
#endif /* RTEMS_LIB_FLIP_FLOP_H */
|
||||||
|
|
||||||
No newline at the end of the file.
|
No newline at the end of the file.
|
||||||
|
|
||||||
Source File Example
|
Source File Example
|
||||||
^^^^^^^^^^^^^^^^^^^
|
-------------------
|
||||||
|
|
||||||
.. code-block:: c
|
.. code-block:: c
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* @file
|
* @file
|
||||||
@ -344,16 +342,22 @@ Source File Example
|
|||||||
}
|
}
|
||||||
|
|
||||||
Files
|
Files
|
||||||
^^^^^
|
-----
|
||||||
|
Document files with the ``@file`` directive omitting the optional filename
|
||||||
Document files with the @file directive omitting the optional filename argument. Doxygen will infer the filename from the actual name of the file. Within one Doxygen run all files are unique and specified by the current Doxyfile. We can define how the generated output of path and filenames looks like in the Doxyfile via the FULL_PATH_NAMES, STRIP_FROM_PATH and STRIP_FROM_INC_PATH options.
|
argument. Doxygen will infer the filename from the actual name of the file.
|
||||||
|
Within one Doxygen run all files are unique and specified by the current
|
||||||
|
Doxyfile. We can define how the generated output of path and filenames looks
|
||||||
|
like in the Doxyfile via the ``FULL_PATH_NAMES``, ``STRIP_FROM_PATH`` and
|
||||||
|
``STRIP_FROM_INC_PATH`` options.
|
||||||
|
|
||||||
Functions
|
Functions
|
||||||
^^^^^^^^^
|
---------
|
||||||
|
|
||||||
For documentation of function arguments there are basically to ways: The first one uses @param:
|
For documentation of function arguments there are basically to ways:
|
||||||
|
|
||||||
.. code-block::
|
The first one uses ``@param``:
|
||||||
|
|
||||||
|
.. code-block:: c
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* @brief Copies from a source to a destination memory area.
|
* @brief Copies from a source to a destination memory area.
|
||||||
@ -364,32 +368,35 @@ For documentation of function arguments there are basically to ways: The first o
|
|||||||
* @param[in] src The source memory area to copy from.
|
* @param[in] src The source memory area to copy from.
|
||||||
* @param[in] n The number of bytes to copy.
|
* @param[in] n The number of bytes to copy.
|
||||||
*/
|
*/
|
||||||
The second is to use @a param in descriptive text, for example:
|
|
||||||
|
The second is to use ``@a`` param in descriptive text, for example:
|
||||||
|
|
||||||
|
.. code-block:: c
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* Copies @a n bytes from a source memory area @a src to a destination memory
|
* Copies @a n bytes from a source memory area @a src to a destination memory
|
||||||
* area @a dest, where both areas may not overlap.
|
* area @a dest, where both areas may not overlap.
|
||||||
*/
|
*/
|
||||||
|
|
||||||
The @a indicates that the next word is a function argument and deserves some kind of highlighting. However, we feel that @a buries the usage of function arguments within description text. In RTEMS sources, we prefer to use @param instead of @a.
|
The ``@a`` indicates that the next word is a function argument and deserves
|
||||||
|
some kind of highlighting. However, we feel that ``@a`` buries the usage of
|
||||||
|
function arguments within description text. In RTEMS sources, we prefer to
|
||||||
|
use ``@param`` instead of ``@a``.
|
||||||
|
|
||||||
Doxyfile Hints
|
Doxyfile Hints
|
||||||
^^^^^^^^^^^^^^
|
--------------
|
||||||
|
|
||||||
Header Files
|
Header Files
|
||||||
------------
|
~~~~~~~~~~~
|
||||||
|
|
||||||
TBD - This is out of date since the include file reorganizaiton
|
It is an RTEMS build feature that header files need to be installed in order to
|
||||||
|
be useful. One workaround to generate documentation which allows automatic
|
||||||
|
link generation is to use the installed header files as documentation input.
|
||||||
|
Assume that we have the RTEMS sources in the rtems directory and the build of
|
||||||
|
our BSP in build/powerpc-rtems5/mybsp relative to a common top-level directory.
|
||||||
|
Then you can configure Doxygen like:
|
||||||
|
|
||||||
It is an RTEMS build feature that header files need to be installed
|
.. code-block::
|
||||||
in order to be useful. One workaround to generate documentation which
|
|
||||||
allows automatic link generation is to use the installed header files as
|
|
||||||
documentation input. Assume that we have the RTEMS sources in the rtems
|
|
||||||
directory and the build of our BSP in build/powerpc-rtems5/mybsp relative
|
|
||||||
to a common top-level directory. Then you can configure Doxygen like:
|
|
||||||
|
|
||||||
|
|
||||||
.. code-block::
|
|
||||||
|
|
||||||
INPUT = rtems/bsps/powerpc/mybsp \
|
INPUT = rtems/bsps/powerpc/mybsp \
|
||||||
rtems/c/src/lib/libcpu/powerpc/mycpu \
|
rtems/c/src/lib/libcpu/powerpc/mycpu \
|
||||||
@ -407,13 +414,14 @@ to a common top-level directory. Then you can configure Doxygen like:
|
|||||||
rtems
|
rtems
|
||||||
|
|
||||||
Script and Assembly Files
|
Script and Assembly Files
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
Doxygen cannot cope with script (= files with #-like comments) or assembly
|
Doxygen cannot cope with script (= files with #-like comments) or assembly
|
||||||
files. But you can add filter programs for them (TODO: Add source code
|
files. But you can add filter programs for them
|
||||||
for filter programs somewhere):
|
|
||||||
|
|
||||||
.. code-block::
|
.. COMMENT: TBD - Add source code for filter programs somewhere
|
||||||
|
|
||||||
|
.. code-block::
|
||||||
|
|
||||||
FILTER_PATTERNS = *.S=c-comments-only \
|
FILTER_PATTERNS = *.S=c-comments-only \
|
||||||
*.s=c-comments-only \
|
*.s=c-comments-only \
|
||||||
@ -422,9 +430,9 @@ for filter programs somewhere):
|
|||||||
*.ac=script-comments-only
|
*.ac=script-comments-only
|
||||||
|
|
||||||
Assembly Example
|
Assembly Example
|
||||||
^^^^^^^^^^^^^^^^
|
~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
.. code-block::
|
.. code-block:: c
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* @fn void mpc55xx_fmpll_reset_config()
|
* @fn void mpc55xx_fmpll_reset_config()
|
||||||
@ -442,9 +450,9 @@ Assembly Example
|
|||||||
You have to put a declaration of this function somewhere in a header file.
|
You have to put a declaration of this function somewhere in a header file.
|
||||||
|
|
||||||
Script Example
|
Script Example
|
||||||
^^^^^^^^^^^^^^
|
~~~~~~~~~~~~~~
|
||||||
|
|
||||||
.. code-block:: shell
|
.. code-block:: shell
|
||||||
|
|
||||||
##
|
##
|
||||||
#
|
#
|
||||||
@ -455,17 +463,17 @@ Script Example
|
|||||||
# @brief Configure script of LibBSP for the MPC55xx evaluation boards.
|
# @brief Configure script of LibBSP for the MPC55xx evaluation boards.
|
||||||
#
|
#
|
||||||
|
|
||||||
AC_PREREQ(2.60)
|
AC_PREREQ([2.69])
|
||||||
AC_INIT([rtems-c-src-lib-libbsp-powerpc-mpc55xxevb],[_RTEMS_VERSION],[http://www.rtems.org/bugzilla])
|
AC_INIT([rtems-c-src-lib-libbsp-powerpc-mpc55xxevb],[_RTEMS_VERSION],[https://devel.rtems.org/newticket])
|
||||||
|
|
||||||
|
|
||||||
GCC Attributes
|
GCC Attributes
|
||||||
^^^^^^^^^^^^^^
|
--------------
|
||||||
|
|
||||||
The Doxygen C/C++ parser cannot cope with the GCC attribute((something))
|
The Doxygen C/C++ parser cannot cope with the GCC ``attribute((something))``
|
||||||
stuff. But you can discard such features with pre-defined preprocessor
|
stuff. But you can discard such features with pre-defined preprocessor macros
|
||||||
macros:
|
|
||||||
|
|
||||||
.. code-block:: shell
|
.. code-block:: shell
|
||||||
|
|
||||||
ENABLE_PREPROCESSING = YES
|
ENABLE_PREPROCESSING = YES
|
||||||
MACRO_EXPANSION = YES
|
MACRO_EXPANSION = YES
|
||||||
|
Loading…
x
Reference in New Issue
Block a user