|
|
|
|
|
Go to the source code of this file.
True, in this simple example, nearly all of the functionality of the shell scripts (eventually) called by this one (e.g., 31*.b and 32*.b, and deeper down 35*.b and 55*.b) could be placed into this file.
However, this is only a simple example. In my real world, a documentation suite includes several doxygen projects. Plus, I have many different documentation suites covering different aspects of our code and aimed at different (mostly internal) audiences.
In my environment, a given documentation suite has multiple 30*.b files, which call associated 31*.b and 32*.b files. (Lately, I've been wrapping yet another 30_build_all.b around all of the 30*.b files which can be hooked into the software build process.)
With respect to the 31*.b and 31*.b separation, I found it beneficial to compartmentalize the CVS checkout procedures (31*.b) from the actual doxygen calls (32*.b), because it facilitated the maintenance/tweak mode better. I could focus on one project and one area of a project to get it correct when doing partial system builds.
Moreover, I found many operations that either were repeated frequently within the build process or were being forgotten whenever I tried to do a partial build. These were pulled out into 35*.b and 55*.b files. Yes, in some cases, certain perl programs are called multiple times on the same set of information. The run-time inefficiencies and delays (seconds) in repeating operations was deemed acceptable in comparison to the alternative, which was a compromise in the integrity of the system (readily evident in the TOC or index) if I forgot a step in the partial build process.
Definition in file 30_tp_tools.b.
|
|
|
Open-Source tools compliments of Voyant Technologies, Inc. and Glenn C. Maxey.
01/13/2003
TP Tools v2-00-0a
# tpt-script-hcr-02