From: Miguel A. Figueroa-V. <mi...@ie...> - 2009-04-27 15:32:56
|
On Mon, Apr 27, 2009 at 11:03 AM, Tim Cootes wrote: > This sounds like a good idea. > Having to manage the library_list.txt as a separate file is a bit unwieldy. > Having something integrated more directly into CMakeLists.txt is likely to > be much easier to remember and manage. That's what I thought. > Does this mean that it would only generate the documentation for the modules > currently being built (defined by the flags in the CMakeCache.txt)? Yes. However, you don't need to actually build anything except the documentation if you just run the 'make build_doxygen_doc' target. So, we could have a nightly build with everything activated, which configures with cmake and runs this target. Running doxygen for a subset of the libraries can be handled much easier by manipulating the list of libraries gathered after the configure step. But getting the libs into this list requires that the CMakeLists.txt file is processed, so if you turn off BUILD_CORE_IMAGING you will not get the vil lib into the list. > Secondly, can the system be easily modified to build documentation for > internal libraries (ie not part of the VXL tree, but will depend on the VXL > classes)? Well, I haven't tested it like that, but if I haven't missed anything, you could simply have the same DOXYGEN_OUTPUT_DIR in both builds and then you can have something like: doxygen_add_library(src/tims_lib contrib/mul/mbl core/vul core/vbl) It should create the correct links from the internal sources to the vxl sources in the doxygen html output. --Miguel |