[CMake] Double redefinition of commands...

[Andreas Schuh]

I just realized that the second solution has one flaw.

You will need to reset the guard variable in the root CMakeLists.txt file via

set (CUSTOM_COMMANDS_INCLUDED 0 CACHE INTERNAL "" FORCE)

--Andreas

On May 24, 2011, at 10:37 AM, Andreas Schuh wrote:

> 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
>