Re: [CMake] Making a variable a dependency...
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
#includestdio.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
--
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] Making a variable a dependency...
Alexander Neundorf said the following on 2/6/2012 3:56 PM: 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 ? We're working in a client/server environment in a fairly agile production environment; we need to have /all/ executables correctly stamped with the revision they're sourced from. So I kind of need it run before each build. Further, one of my problems is that right now the variable gets cached in CMakeCache.txt, so I have to delete CMakeCache.txt or do cmake -DSubversion_FOUND=NO or similar. In the short term, I can just make it always rebuild the revision.h, but that has the downside of causing it to /always/ rebuild the library that includes it, causing all binaries to relink, and so on, which is fairly time consuming (it's a very large project :) -- 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] Making a variable a dependency...
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
#includestdio.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?
- Oliver
--
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] Making a variable a dependency...
On Sat, Feb 4, 2012 at 11:35 PM, Oliver Smith osm...@playnet.com 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? I had the same problem and I decided it does not worth to tackle it perfectly. Actually, you only need the right revision.h at release time. So in my project I had a 'release' target with this behavior: 1/ tag the repository 2/ make rebuild_cache 3/ make all 4/ make package Also, this could be simplify since I think it is safer to make a release from a clean build directory so you can just skip the first two step and just tell your release script to checkout the right revision before to do a cmake, make, make package. During development phase if you really want to have the proper revision.h, I would suggest to add a 'force-revision' target which recompute the revision number and regenerate the revision.h header. I know I did not really answer your question but this solution is good enough and does not require any tricks. Also I don't think it worth running cmake each time make is called. Regards, -- Nicolas Desprès -- 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] Making a variable a dependency...
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 ? 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
Re: [CMake] Making a variable a dependency...
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.
Regards,
Michael
--
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] Making a variable a dependency...
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? -- 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
