From: Miguel A. Figueroa-V. <mi...@ie...> - 2009-04-25 14:00:03
|
I have an initial implementation of support for a CMake driven doxygen documentation build. The idea is that if someone wants to build the documentation he only needs to turn BUILD_DOCUMENTATION on in CMake. This also means that the automatic build can be done using CTest. The way it works is that I use the following macro in CMakeLists.txt file to gather the information required into a doxygen_configuration.cmake file generated at the binary directed and then whenever the custom target build_doxygen_doc is run it produces the docs. doxygen_add_library(<library> <library_deps>) For example: doxygen_add_library(contrib/gel/mrc/vpgl core/vcsl core/vgl core/vnl core/vsl) I could parse a file like the current method with scripts/doxy/data/library_list.txt, but I think having this macro is easier to maintain as it is close to everything else (i.e., if a dependency is added to target_link_libraries you'll likely remember to add it in the doxygen_add_library which is in the next line). I still don't have support for not building the docs if nothing has changed (like the old system had by parsing cvs update output), but it may be easy to achieve by parsing the 'svn info' output. Before I proceed to fine tune the system I would like feedback on whether this is a good direction (meaning I can soon checkin a version to replace the current system), otherwise I'll stop and use it only to build my stuff here to inspect the doxygen output. --Miguel |
From: Brendan M. <bre...@gm...> - 2009-04-26 21:44:06
|
Hi Miguel, I think a cmake driven doxygen build would be a good thing. But from memory, the doxygen builds take quite a long time, so I think it's going to be quite important that the docs don't get built if things haven't changed. -- Cheers, Brendan |
From: Tim C. <tim...@ma...> - 2009-04-27 15:03:26
|
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. Does this mean that it would only generate the documentation for the modules currently being built (defined by the flags in the CMakeCache.txt)? 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)? Tim Tim Cootes Professor of Computer Vision Imaging Science and Biomedical Engineering tel (+44) 0161 275 5146 The University of Manchester fax (+44) 0161 275 5145 Manchester M13 9PT , UK mailto:t.c...@ma... http://www.isbe.man.ac.uk/~bim -----Original Message----- From: Miguel A. Figueroa-Villanueva [mailto:mi...@ie...] Sent: Sat 4/25/2009 2:59 PM To: Vxl-maintainers Subject: [Vxl-maintainers] CMake driven doxygen build. I have an initial implementation of support for a CMake driven doxygen documentation build. The idea is that if someone wants to build the documentation he only needs to turn BUILD_DOCUMENTATION on in CMake. This also means that the automatic build can be done using CTest. The way it works is that I use the following macro in CMakeLists.txt file to gather the information required into a doxygen_configuration.cmake file generated at the binary directed and then whenever the custom target build_doxygen_doc is run it produces the docs. doxygen_add_library(<library> <library_deps>) For example: doxygen_add_library(contrib/gel/mrc/vpgl core/vcsl core/vgl core/vnl core/vsl) I could parse a file like the current method with scripts/doxy/data/library_list.txt, but I think having this macro is easier to maintain as it is close to everything else (i.e., if a dependency is added to target_link_libraries you'll likely remember to add it in the doxygen_add_library which is in the next line). I still don't have support for not building the docs if nothing has changed (like the old system had by parsing cvs update output), but it may be easy to achieve by parsing the 'svn info' output. Before I proceed to fine tune the system I would like feedback on whether this is a good direction (meaning I can soon checkin a version to replace the current system), otherwise I'll stop and use it only to build my stuff here to inspect the doxygen output. --Miguel ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Vxl-maintainers mailing list Vxl...@li... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
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 |