All geek questions in one place

Optimal configuration for Doxygen in a large COM project with multiple applications

The system has up to 100 VC ++ projects, each of which spits out a DLL or EXE. In addition, there are many COM components with IDL and generated .h / .c files.

What is the “right way” or at least a good way to organize this with Doxygen? One common doxy project or one project / solution? And what is the right way to handle COM that generated code and a lot of fluff that inflates generated HTML files.

+4
source share
3 answers

I have not yet had the opportunity to try this, but Doxygen has the ability to link to external documentation . I would probably do individual projects and experiment using external binding. Otherwise, with a large number of projects that you describe, one build of oxygen can take a very long time.

+1
source

If you do not want certain files to be included in your Doxygen output, you can use the EXCLUDE_PATTERNS directive. One project I'm working on uses

EXCLUDE_PATTERNS = */test/*

to avoid including our unit test classes in Doxygen output. If your auto-generated COM files have any pattern for them, you can exclude them this way.

+1
source

I selected several separate doxygen builders as follows:

  • Create a top-level library for the main application, not including libraries.
  • Create separate "libs" documents for each library
  • If necessary, create a "global" doxygen construct with all
  • If necessary, create libraries with the "Internal" switch on.
  • All output was contained in one Doxygen folder ( Doxygen\application , Doxyge\Lib1... )
  • Using. The top-level lib assembly uses the "main page" with links to library functions, for example, <a href="../_Lib1/html/index.html">Lib #1</a>
  • Libs has a master page with a link to the lib master page at the top level: for example, href="../../_TopLevel/html/index.html"

Not sure about COM ...

Steve

0
source

Source: https://habr.com/ru/post/1312971/

More articles:


All Articles