On 08/20/2010 12:42 PM, Michael Wild wrote: > > On 19. Aug, 2010, at 23:36 , Michael Hertling wrote: > >> On 08/19/2010 09:42 PM, Michael Wild wrote: >>> >>> In that case I recommend creating a CMake script (e.g. >>> create_application_version.cmake) which creates the ApplicationVersion.xml >>> file. It queries the current revision (have a look at FindSVN.cmake on how >>> to do this), determines the date and time (this is a problem, refer to this >>> thread for more info: >>> http://www.mail-archive.com/cmake@cmake.org/msg30662.html) and then either >>> does a configure_file() or a file(WRITE) to create ApplicationVersion.xml. >>> Ideally the create_application_version.cmake is also a configured file >>> (with the path to the build and source tree and the path to the svn >>> executable etc.). >>> >>> This script is then invoked by a custom command: >>> >>> # dummy_file is never created... >>> add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/ApplicationVersion.xml >>> ${CMAKE_BINARY_DIR}/dummy_file >>> COMMAND ${CMAKE_EXECUTABLE} -P >>> ${CMAKE_BINARY_DIR}/create_application_version.cmake >>> COMMENT "Creating ApplicationVersion.xml" >>> VERBATIM >>> ) >>> >>> # this intentionally depends on dummy_file, which is never created >>> add_custom_target(create_appplication_version ALL >>> DEPENDS ${CMAKE_BINARY_DIR}/ApplicationVersion.xml >>> ${CMAKE_BINARY_DIR}/dummy_file) >>> >>> add_executable(super_duper main.cpp >>> ${CMAKE_BINARY_DIR}/ApplicationVersion.xml) >>> add_dependencies(super_duper create_appplication_version) >>> >>> >>> The trick I'm trying to pull off, is that super_duper depends on >>> create_appplication_version, which is always out of date and depends on the >>> non-existing file dummy_file, thus always updating ApplicationVersion.xml. >>> Not that I haven't tested this. >> >> Possibly, this may be simplified: The COMMAND can be transferred from >> the custom command to the custom target, so the former goes away and >> one doesn't need a dummy file for triggering. Furthermore, the custom >> target doesn't need to be declared ALL, and the ApplicationVersion.xml >> doesn't need to appear in ADD_EXECUTABLE(), but as it's no header and, >> thus, not subject to CMake's dependency scanning, one has to imply an >> explicit dependency through the OBJECT_DEPENDS source file property on >> main.cpp to ensure the executable's rebuild when ApplicationVersion.xml >> changes. > > Ahh, I forgot about the OBJECT_DEPENDS. And you also need to set the > GENERATED property to TRUE on the ApplicationVersion.xml file if you leave > away the custom command, otherwise CMake will complain at configure time. But > all-in-all probably simpler, and you don't need the despicable dummy_file.
Yes, the GENERATED property should be set, but if there's a template named ApplicationVersion.xml.in CMake won't complain about a missing ApplicationVersion.xml not marked as GENERATED since it checks for a ".in" extension automatically. >> The create_application_version.cmake should use CONFIGURE_FILE() to >> generate the ApplicationVersion.xml since this function doesn't write >> a new output file if it wouldn't differ from the previous one, so the >> ApplicationVersion.xml doesn't trigger rebuilds if it doesn't actually >> change. At <http://www.cmake.org/pipermail/cmake/2010-July/037958.html> >> and <http://www.cmake.org/pipermail/cmake/2010-July/038015.html>, you'll >> find a similar discussion. > > If he's going to encode the time that probably won't matter, since the file > will most likely always differ... Yes, and I assume it's not the OP's desire to trigger a rebuild because of a hand's leap. ;) Hence, what should be done is to generate one file with the version and another file with the timestamp, preferably by the same custom target, but to impose a dependency on the version file only. So, the version and the timestamp are regenerated each time a concerned target is checked for being up to date, but solely a new version will trigger a rebuild. 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
