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.

> 
> 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...

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

Reply via email to