[CMake] installing generated files

[David Cole]

I would think:
INSTALL(DIRECTORY ....)

would do it in one command without knowledge of the sub-structure of the
directory.

Is there something wrong with that approach?

It should be less error prone than gathering knowledge of doxygen output
just for specifying a bunch of install rules that essentially say "install
all the files under this directory using the same structure under that other
directory..."


HTH,
David


On 11/28/07, Stefan Kögl <skoegl at online.de> wrote:
>
> Am Mittwoch, 28. November 2007 10:38:20 schrieb Brandon Van Every:
> > You need to know the names of the files that will be generated and
> > then INSTALL(FILES ...)
> > Typically I just have a hardwired list of root words, from which I
> > derive .cxx .hxx and whatever a doxygen suffix is.  Here are some
> > helper routines.  You're probably also going to want an
> > ADD_CUSTOM_COMMAND so you can specify file outputs, rather than having
> > to always run doxygen.
> >
>
> This is really cumbersomely. Then I have to know how doxygen determines
> the
> output file names, and update the "root list" by hand every time I create,
> rename, and remove a file or function.
>
> After googling one more time I found this solution.
>
> http://www.cmake.org/pipermail/cmake/2007-January/012775.html
>
> ###################################
> new CMakeLists.txt
> ###################################
>
> PROJECT(doxygen)
> FIND_PACKAGE(Doxygen REQUIRED)
>
> CONFIGURE_FILE(${doxygen_SOURCE_DIR}/Doxyfile.in
>             ${doxygen_BINARY_DIR}/Doxyfile)
>
> FILE(MAKE_DIRECTORY ${doxygen_BINARY_DIR})
>
> ADD_CUSTOM_TARGET(docs-doxygen ALL
>     COMMAND ${DOXYGEN_EXECUTABLE} ${doxygen_BINARY_DIR}/Doxyfile
>     DEPENDS ${doxygen_BINARY_DIR}/Doxyfile
>     VERBATIM)
>
> INSTALL(CODE "
>     FILE(GLOB DOXYGEN_OUTPUT ${doxygen_BINARY_DIR}/html/*)
>     FILE(INSTALL DESTINATION ${PERTUBIS_DOC_PATH}/html TYPE FILE FILES
> \${DOXYGEN_OUTPUT})
>     ")
>
> ##################################
>
> The "FILE(INSTALL ...." signature is still undocumented, but it works. Is
> this
> solution "future-proof"?
>
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20071128/eec41160/attachment.html