Revision history [back]

No, I don't believe this is supported.

And generating the manifest (or updating it) as part of the build would also not be possible, as it's used before a build is even started.

What I've done in the past is to handle this "in the other direction": see ros-industrial/abb_robot_driver/abb_egm_hardware_interface/CMakeLists.txt for an example.

Probably not acceptable in your case, but it works pretty well and avoids having to update a version nr in multiple places.

No, I don't believe this is supported.

And generating the manifest (or updating it) as part of the build would also not be possible, as it's used before a build is even started.

What I've done in the past is to handle this "in the other direction": see ros-industrial/abb_robot_driver/abb_egm_hardware_interface/CMakeLists.txt for an example.example:

Probably not acceptable in your case, but it works pretty well and avoids having to update a version nr in multiple places.

No, I don't believe this is supported.

And generating the manifest (or updating it) as part of the build would also not be possible, as it's used before a build is even started.

What I've done in the past is to handle this "in the other direction": see ros-industrial/abb_robot_driver/abb_egm_hardware_interface/CMakeLists.txt for an example:

file(READ "${CMAKE_CURRENT_SOURCE_DIR}/package.xml" package_xml_str)

# Extract project version.
if(NOT package_xml_str MATCHES "<version>([0-9]+.[0-9]+.[0-9]+)</version>")
  message(FATAL_ERROR "Could not parse project version from package manifest (aborting)")
else()
  set(extracted_version ${CMAKE_MATCH_1})
endif()

project(... VERSION ${extracted_version} ...)

Probably not acceptable in your case, but it works pretty well and avoids having to update a version nr in multiple places.