[CMake] Creating custom file before building/compiling with cmake

[Michael Wild]

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