[CMake] Double redefinition of commands...

Andreas Schuh andreas.schuh.84 at googlemail.com
Tue May 24 10:37:16 EDT 2011


Hi Theodore,

Your observation is interesting, I had expected CMake to not remember function definitions across subtrees similar to non-cached variables. Apparently, it does not store function and macro definitions on a stack.

However, what you still could do is either one of the following or maybe even better both combined.

1. Define all your custom CMake functions/macros in separate CMake module(s) which are part of a base package all your projects make use of. This also avoids the duplication of code. You only will need to fix/enhance the implementation of your custom commands in this separate package if necessary.

2. Similar to the guards in C/C++ header files, do the following in the module(s) that define your custom functions

  if (NOT CUSTOM_COMMANDS_INCLUDED)
  set (CUSTOM_COMMANDS_INCLUDED 1 CACHE INTERNAL "Whether custom commands were defined already" FORCE)

  function (find_package)
     # ....
     _find_package (${ARGN})
     # ....  
  endfunction ()

  endif (NOT CUSTOM_COMMANDS_INCLUDED)

If CMake would forget the definition of functions when you traverse into a different subtree of the sources, you would simply not cache the value of the guard variable.

Andreas 

On May 20, 2011, at 9:10 AM, Theodore Papadopoulo wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 05/19/2011 10:14 PM, Alexander Neundorf wrote:
>> On Thursday 19 May 2011, Theodore Papadopoulo wrote:
>> 
>> This feature is not very, let's say polished, so yes, it is not perfect as it 
>> is.
>> Why do you want do do this ?
> 
> Basically, I want find_library to re-run in the case some variables have
> been changed. The most common case, is a static/dynamic build.
> If the user switches between a static vs dynamic build, I want the
> propser static/dynamic libraries to be found. We currently emulate this
> with a code such like this:
> 
> SET(LIB_TYPE SHARED)
> 
> OPTION(BUILD_SHARED_LIBS "Build shared libs" ON)
> MARK_AS_ADVANCED(BUILD_SHARED)
> 
> IF (BUILD_SHARED)
>    SET(LIB_TYPE SHARED)
> ELSE()
>    SET(LIB_TYPE STATIC)
> ENDIF()
> 
> STRING(COMPARE NOTEQUAL "${BUILD_SHARED_STATUS}" ""
> BUILD_SHARED_STATUS_NOT_EMPTY)
> IF(BUILD_SHARED_STATUS_NOT_EMPTY)
>    STRING(COMPARE NOTEQUAL "${BUILD_SHARED_STATUS}" "${BUILD_SHARED}"
> RESET)
> ENDIF()
> 
> # Store in cache previous value of BUILD_SHARED
> SET(BUILD_SHARED_STATUS "${BUILD_SHARED}" CACHE INTERNAL "Previous
> shared status" FORCE)
> 
> FUNCTION(FIND_LIBRARY VAR)
>    IF(${RESET})
>        SET(${VAR} NOTFOUND CACHE STRING "" FORCE)
>    ENDIF()
>    MESSAGE("HERE")
>    _FIND_LIBRARY(${VAR} ${ARGN})
>    MARK_AS_ADVANCED(${VAR})
> ENDFUNCTION()
> 
> ... and the idea was to use the standard find_library so as to catch all
> the uses of the libraries without having to tell to use our own
> version... and that worked quite well untill I had to combine two
> projects that define this same macro !!!
> 
>> How about adding a "my_find_library()", so you don't have to rename it ?
>> In KDE4 we have KDE4_ADD_EXECUTABLE(), KDE4_ADD_LIBRARY() which add some 
>> features, and developers who want to make use of this have to use these 
>> functions.
> 
> Well, I guess I'll have to do something similar. I do not find that
> quite robust and efficient, but for the time being that's the best
> solution...
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk3WaEgACgkQEr8WrU8nPV3hEwCglem+kDG36hi21Jz9K4VU1H6H
> qpIAoLPd9IfU465eRG6AczvZKN0CuRAO
> =uVKk
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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



More information about the CMake mailing list