Thank you for the idea Benoit. That definitely solves the problem (although not elegantly).
I would actually prefer to generate the documentation for A, B, and C all in one config file. However, this creates a whole different set of issues. I would expect the related output files for project A to be located in A/html and not in some monolithic directory with the output for B and C. The typical approach doxygen takes, as you know, is to place the documentation for A, B, and C in a single directory. Is there a way to make it put output files for various projects in a specific directory inside of both A, B, and C (depending on which is being processed)? On Sat, Mar 28, 2009 at 1:19 PM, Benoit <[email protected]> wrote: > As i can see you also use cmake to generate your project, therefore you can > use it to generate doxygen. > you can generate a doxyfile for each library to geneate only doxygen > TAGFILE. > then you can generate another doxygen file that generate you the complete > documentation in a second pass using the tagfile. > > This is just an idea but i never try it because i'm generating > documentation in one step because my libraries have linear depencies. > > libcore > no depency > libio > depend on libcore > main > depend on libio and libcore. > > -- > Benoit RAT > www.neub.co.nr > > > On Sat, Mar 28, 2009 at 4:26 PM, Robert Dailey <[email protected]> wrote: > >> The thing is, I'm generating all of the projects myself. I have 3 >> different doxygen config files for 3 projects (Remember A, B, C before in my >> previous example). In addition, the order in which I process each project is >> linear and their dependencies are not. >> What I really need is the ability to tell doxygen to do a "first pass" >> that does nothing more than generate tag files for projects that specify it >> with GENERATE_TAGFILE. If a project does not have this, it is simply >> ignored. I can then do a "second pass" which is the full build of >> documentation. Except this time, all of the tag files have been generated so >> it doesn't matter which order I build them in. >> >> Chances are, most projects will do both: They will generate a tag file and >> also reference other tag files. All paths will be local, no URLs will be >> used to reference tag files. >> >> >> On Sat, Mar 28, 2009 at 6:44 AM, Benoit <[email protected]> wrote: >> >>> Hy, >>> >>> You should generate a B.tag file for the B library by setting in >>> B.doxyfile the parameters: GENERATE_TAGFILE = B.tag >>> Then you could use B documentation in A by setting in A.doxyfile the >>> parameters: TAGFILES : B.tag=http://yourserver/yourBdocpath/ >>> >>> Hope it can help you! >>> >>> The only probleme you can have is the cross-dependencies, but it also a >>> big probleme at link stage so you shouldn't have it. >>> >>> >>> -- >>> Benoit RAT >>> www.neub.co.nr >>> >>> >>> On Sat, Mar 28, 2009 at 12:27 AM, Robert Dailey <[email protected]>wrote: >>> >>>> Hi, >>>> Suppose I have three C++ libraries called A, B, and C. >>>> >>>> Each project has its own doxygen configuration file and doxygen >>>> processes documentation for each of them independently. The HTML output for >>>> each is located in A/html, B/html, and C/html on the filesystem. >>>> >>>> If A has an explicit dependency on B (i.e., A uses classes from library >>>> B), how can I ensure that the HTML documentation for A knows how to find >>>> the >>>> documentation for B so that it may link to B's appropriate HTML files? >>>> There >>>> is the possibility of having to reference identifiers located in B's >>>> documentation from A's documentation. >>>> >>>> If the best solution for this ends up being that I need to generate >>>> documentation for A, B, and C all in one go, what is the best way to do >>>> this? >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Doxygen-users mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/doxygen-users >>>> >>>> >>> >> >
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
