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