Changes between Version 4 and Version 5 of GCI/Documentation/DoxygenForBSPs


Ignore:
Timestamp:
10/23/18 18:09:43 (6 years ago)
Author:
Joel Sherrill
Comment:

Change more libbsp to bsps

Legend:

Unmodified
Added
Removed
Modified

  • GCI/Documentation/DoxygenForBSPs

    v4 v5  
    1919===  Outline of Structure  ===
    2020
    21 The structure of the doxygen in libbsp should match the structure of libbsp itself as closely as possible. Let's start by looking carefully at how libbsp is structured.
     21The structure of the doxygen in BSPs should match the structure of the bsps/ directory itself as closely as possible. Let's start by looking carefully at how the bsps/ directory is structured.
    2222
    23 The libbsp directory itself is very well ordered. Considered at the root, the first level contains directories of each cpu architecture RTEMS currently supports, along with a folder containing files and headers shared between all architectures.
     23The bsps/ directory itself is very well ordered. Considered at the root, the first level contains directories of each cpu architecture RTEMS currently supports, along with a folder containing files and headers shared between all architectures.
    2424
    2525{{{
    … …  
    3131}}}
    3232
    33 If we cd into a specific architecture, we see that a similar structure is employed. libbsp/arm/ contains directories for each Board Support Package for boards with an ARM cpu, along with a folder for files and .h's shared by all BSPs of that architecture.
     33If we cd into a specific architecture, we see that a similar structure is employed. bsps/arm/ contains directories for each Board Support Package for boards with an ARM cpu, along with a folder for files and .h's shared by all BSPs of that architecture.
    3434
    3535{{{
    … …  
    5151}}}
    5252
    53 The goal is for someone to be able to search through the doxygen is a very similar way. The way to accomplish this would be to have a single libbsp parent module that would contain a submodule for each cpu architechture, which in turn would contain submodules for each BSP. Modules for shared and generic functions would be defined at each level, whenever appropriate. Rememember, our goal is for the structure of doxygen modules and submodules to match the structure of libbsp as closely as possible.
     53The goal is for someone to be able to search through the doxygen is a very similar way. The way to accomplish this would be to have a single BSPs parent module that would contain a submodule for each CPU architechture, which in turn would contain submodules for each BSP. Modules for shared and generic functions would be defined at each level, whenever appropriate. Remember, our goal is for the structure of doxygen modules and submodules to match the structure of the bsps/ directory as closely as possible.
    5454
    55 The overarching parent module that all other modules should belong to is bsp_kit, whose @defgroup is found in /shared/include/bootcard.h Consider this to be the "root directory" for libbsp doxygen purposes.
     55The overarching parent module that all other modules should belong to is bsp_kit, whose @defgroup is found in bsps/shared/include/bootcard.h Consider this to be the "root directory" for BSPs doxygen purposes.
    5656
    5757{{{
    … …  
    5959}}}
    6060
    61 The first thing that should be @ingroup to this bsp_kit module (I will use module and group interchangably) should be submodules for each architechture. This group should have the "@defgroup *bsp_architechture*" placed in one of shared header files that is sufficiently generic. The specific location of this @defgroup does not matter, you can place the @defgroup in a file and not add the file to the group (even though you should add it, unless it belongs in a more specific submodule). For example, the @defgroup for the arm architecture is found in arm/shared/include/start.h
     61The first thing that should be @ingroup to this bsp_kit module (I will use module and group interchangably) should be submodules for each architecture. This group should have the "@defgroup *bsp_architechture*" placed in one of shared header files that is sufficiently generic. The specific location of this @defgroup does not matter, you can place the @defgroup in a file and not add the file to the group (even though you should add it, unless it belongs in a more specific submodule). For example, the @defgroup for the arm architecture is found in arm/shared/include/start.h
    6262
    6363{{{