Optimal setup for Doxygen in a large multi-application COM project
A system has up to 100 VC++ projects, each spitting out a DLL or EXE. In addition there are many COM components with IDL and generated .h/.c files.
What's 'the right way' or at least a good way to organise this with Doxygen? One overall doxy project or one per project/solution? And what's the right way to handle COM, which has g开发者_开发问答enerated code and a lot of 'fluff' that will bloat generated HTML files.
If you don't want certain files to be included in your Doxygen output, you can use the EXCLUDE_PATTERNS directive. One project I work on uses
EXCLUDE_PATTERNS = */test/*
to avoid including our unit test classes in the Doxygen output. If your autogenerated COM files have any sort of pattern to them, you could exclude them this way.
I haven't had a chance to try this out yet, but doxygen has the ability to link to external documentation. I would probably do separate projects, and experiment with using the external linking. Otherwise, with the large number of projects you describe, a single doxygen build could take a very, very long time.
I opted for several separate doxygen builds as follows:
- Build top-level lib for main application, not including libraries
- Build separate "libs" docs for each library
- Optionally build a "global" doxygen build with everything
- Optionally build the libs with "Internal" switch turned on.
- All output was contained in a single Doxygen folder (
Doxygen\application
,Doxyge\Lib1...
) - Use a The top-level lib build uses a "mainpage" with links to the library functions,
e.g.
<a href="../_Lib1/html/index.html">Lib #1</a>
- The libs have a mainpage with a link back to the top-level lib mainpage:
e.g.
href="../../_TopLevel/html/index.html"
Not sure about the COM stuff...
Steve
精彩评论