Re: [CMake] Double redefinition of commands...
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
>
___
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
Re: [CMake] Double redefinition of commands...
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
___
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
Re: [CMake] Double redefinition of commands...
-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
Re: [CMake] Double redefinition of commands...
On Thursday 19 May 2011, Theodore Papadopoulo wrote:
> Hello,
>
> I'm facing with the following problem, I'm using the _XXX trick to
> access the previous version of a command. Unfortunately, this is not
> quite what I need because of a double redefinition of the command.
>
> Here is a small example of the problem I have:
>
> PROJECT(Test)
>
> FUNCTION(FIND_LIBRARY VAR)
> MESSAGE("HERE 1")
> _FIND_LIBRARY(${VAR} ${ARGN})
> ENDFUNCTION()
>
> FIND_LIBRARY(ZLIB z)
>
> FUNCTION(FIND_LIBRARY VAR)
> MESSAGE("HERE 2")
> _FIND_LIBRARY(${VAR} ${ARGN})
> ENDFUNCTION()
>
> FIND_LIBRARY(GTKLIB gtk)
>
> In the second call "FIND_LIBRARY(GTKLIB gtk)", _FIND_LIBRARY refers to
> the first definition and the call to that function just loops forever.
> Browsing cmake sources reveals that basically cmake just renames the old
> function XXX into _XXX. If _XXX already exists, it is suppressed (if I
> understood well).
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 ?
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.
It works well for us.
Alex
___
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
[CMake] Double redefinition of commands...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I'm facing with the following problem, I'm using the _XXX trick to
access the previous version of a command. Unfortunately, this is not
quite what I need because of a double redefinition of the command.
Here is a small example of the problem I have:
PROJECT(Test)
FUNCTION(FIND_LIBRARY VAR)
MESSAGE("HERE 1")
_FIND_LIBRARY(${VAR} ${ARGN})
ENDFUNCTION()
FIND_LIBRARY(ZLIB z)
FUNCTION(FIND_LIBRARY VAR)
MESSAGE("HERE 2")
_FIND_LIBRARY(${VAR} ${ARGN})
ENDFUNCTION()
FIND_LIBRARY(GTKLIB gtk)
In the second call "FIND_LIBRARY(GTKLIB gtk)", _FIND_LIBRARY refers to
the first definition and the call to that function just loops forever.
Browsing cmake sources reveals that basically cmake just renames the old
function XXX into _XXX. If _XXX already exists, it is suppressed (if I
understood well).
What I would need is a reference to the original FIND_LIBRARY (the one
provided by cmake), but I see no way of doing it. Any idea.
Another, probably more powerful idea, would be to allow users to rename
functions as they wish. This is probably not too difficult as Cmake
already contains code to do that.
And finally, no I cannot suppress the two redefinitions as they are in
two different sub-projects that need to be built separately or together.
Any idea will be appreciated.
Thank's a lot.
Theo.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk3VQUkACgkQEr8WrU8nPV1vWQCgo9XBct99/nk0ppMIBaiCvX1F
V78AnAoCdaElXewc6drjrNWcgrAHpXDD
=PYnv
-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
