[CMake] Making a variable a dependency...

Michael Hertling mhertling at online.de
Thu Feb 9 04:32:53 EST 2012


On 02/08/2012 11:13 PM, Oliver kfsone Smith wrote:
> Michael Hertling said the following on 2/6/2012 6:39 PM:
>> On 02/06/2012 10:56 PM, Alexander Neundorf wrote:
>>> On Saturday 04 February 2012, Oliver Smith wrote:
>>>> My CMakeLists uses the Subversion repository information in a couple of
>>>> places (it configures a file revision.h and it uses it for the CPack
>>>> package name).
>>>>
>>>> The problem is that this variable is cached and retained until the cache
>>>> is rebuilt, instead of being calculated or evaluated per make. So if I
>>>> do a build, then do an svn update and pull some changes, it will build a
>>>> new executable but it will stamp it with the revision number from when
>>>> CMake last regenerated the make files...
>>>>
>>>> Is there a way to mark a variable as volatile or something so that CMake
>>>> will always recalculate it and check if it has changed?
>>> Would it be acceptable if cmake would rerun after every build ?
>>> You could enforce that e.g. with a add_custom_command( POST_BUILD ... ) which
>>> could e.g. touch CMakeCache.txt or something.
>>>
>>> Better ideas ?
>> Delay the generation of the revision.h header until build phase
>> via a custom command; look at the following exemplary project:
>>
>> # CMakeLists.txt:
>> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
>> PROJECT(P C)
>> SET(CMAKE_VERBOSE_MAKEFILE ON)
>> ADD_CUSTOM_COMMAND(OUTPUT dummy revision.h
>>      COMMAND ${CMAKE_COMMAND}
>>          -DBD=${CMAKE_BINARY_DIR}
>>          -DWC=${CMAKE_SOURCE_DIR}
>>          -P ${CMAKE_SOURCE_DIR}/revision.cmake)
>> FILE(WRITE ${CMAKE_BINARY_DIR}/main.c
>> "#include<stdio.h>
>> #include \"revision.h\"
>> int main(void)
>> {
>>      printf(\"%d\\n\",REVISION); return 0;
>> }
>> ")
>> ADD_EXECUTABLE(main main.c revision.h)
>>
>> # revision.cmake:
>> FIND_PACKAGE(Subversion)
>> Subversion_WC_INFO(${WC}@HEAD P)
>> FILE(WRITE ${BD}/revision.h.in "#define REVISION @P_WC_REVISION@\n")
>> CONFIGURE_FILE(${BD}/revision.h.in ${BD}/revision.h @ONLY)
>>
>> A "make" run rebuilds the main target whenever the repository's head
>> revision has changed - possibly inappropriate for actual usage, just
>> for demonstration purposes; adapt the revision.cmake script to suit
>> the needs.
>>
>> BTW, can anybody confirm that the above-noted example doesn't work
>> if the order of "dummy" and "revision.h" in the custom command is
>> reversed? AFAICS, revision.h is removed after being generated in
>> this case, so the subsequent compilation fails.
>>
> Unless I'm missing something, that won't work because P_WC_REVISION gets 
> cached in the CMakeCache.txt -- or does using -P cause it to skip the 
> caching?

That's exactly the point: CMake scripts launched by "cmake -P" don't
have access to the cache - refer to the manual - so you can use the
services of FindSubversion.cmake without bothering whether variables
might be stuck in the cache or not. Try the example from my previous
reply and you'll see that P_WC_REVISION doesn't even show up in the
cache at all.

Regards,

Michael


More information about the CMake mailing list