Something like this just came up recently: http://www.cmake.org/pipermail/cmake/2009-October/032725.html
But probably it would be better to patch the subproject... Michael On 13. Nov, 2009, at 5:33 , David Manura wrote:
Is there a way to redefine a built-in function but still keep around a reference to the original function? Example: # wrap "install" function function(install) message("hello!") install(${ARGV}) # original version endfunction() Unfortunately, in the above case, the "install" inside the function refers to the new version of "install", causing an infinite loop. There doesn't appear to be a way to save function references either: set(old_install ${install}) old_install(FILES a DESTINATION b) Neither can I do tricks like adding a subproject that redefines "install" in its own scope. This still overwrites the "install" in the parent project. ~~~ Now, the original problem I'm trying to solve is that I have project maintained by me that does an add_subdirectory on a project maintained by someone else. The subproject does things like install(FILES a.pdf DESTINATION share/doc/foo) but I'd prefer to have its files get stored in my own configurable installation locations, without patching the subproject. This which would be possible if the subproject's CMakeLists.txt did something like this:set(INSTALL_DOC share/doc/foo CACHE PATH "directory for documentation")install(FILES a.pdf DESTINATION ${INSTALL_DOC}) where ${INSTALL_DOC} is a variable that I could redefine in the parent. Another option is if I could simply disable the "install" rules in the subproject and redefine my own in the parent project. I could do that via function(install) endfunction() but now how do I restore the original "install" function in order to install files in the correct locations? I also tried temporarily redefining CMAKE_INSTALL_PREFIX to a temporary directory, but this variable appears to be evaluated after all the "install" commands are processed. Recursively invoking "CMAKE_COMMAND -DCMAKE_INSTALL_PREFIX=${TEMPORARY_FOLDER}" on the subproject may be one solution, but I suspect that might be considered harmful. Maybe I should just patch the subproject. ;)
_______________________________________________ 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
