The .in suffix is merely a convention. Refer to the documentation of the configure_file command for more info.
Michael On 21.08.2010, at 11:04, "Roman Wüger" <noru...@me.com>@mac.com wrote: > So, how must the file "ApplicationVersion.xml.in" looks like? I didn't find > the documentation for the *.in file extensions. > > Thanks in advance > > Best Regards > NoRulez > > Am 21. Aug 2010 um 02:08 schrieb Michael Hertling <mhertl...@online.de>: > >> 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 > > _______________________________________________ > 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
