[CMake] functions as first class objects

David Manura dm.lua at math2.org
Thu Nov 12 23:33:51 EST 2009


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. ;)


More information about the CMake mailing list