[CMake] Changed behavior of CPACK_PACKAGE_VERSION generation?

[Craig Scott]

A little late, but finally got a chance to look at this. In CMake 3.12.0,
the CPack version handling in Modules/CPack.cmake was changed to take its
default from the project version, if set. This was implemented but the
following logic:

if(CMAKE_PROJECT_VERSION_PATCH)

    ...

endif()


This introduced a bug in that a legitimate value of 0 was then treated as
FALSE, so the common case of the value being zero was resulting in the
value being ignored and falling back to the old default, which was 1. This
was fixed in CMake 3.12.1 by changing it to the following:

if(CMAKE_PROJECT_VERSION_PATCH GREATER_EQUAL 0)

    ...

endif()


As part of that same change, the following block of code was also added:

if(NOT DEFINED CPACK_PACKAGE_VERSION)

  set(CPACK_PACKAGE_VERSION "${CPACK_PACKAGE_VERSION_MAJOR}")

  if(CPACK_PACKAGE_VERSION_MINOR GREATER_EQUAL 0)

    string(APPEND CPACK_PACKAGE_VERSION ".${CPACK_PACKAGE_VERSION_MINOR}")

    if(CPACK_PACKAGE_VERSION_PATCH GREATER_EQUAL 0)

      string(APPEND CPACK_PACKAGE_VERSION ".${CPACK_PACKAGE_VERSION_PATCH}")

    endif()

  endif()

endif()


Now, your project has been setting CPACK_PACKAGE_VERSION_PATCH to REPLACEME,
which is not a valid number, so the patch version will no longer be getting
appended to CPACK_PACKAGE_VERSION, as you've observed. This explains at
least the history of what happened. I don't know if it was ever considered
valid to set it to anything other than a number, so it isn't clear whether
this should be considered a regression or not. If you feel strongly enough
that it is, I suggest you create an issue in gitlab
<https://gitlab.kitware.com/cmake/cmake/issues/new> and transfer the
details of this email trail to there.





On Thu, Dec 13, 2018 at 5:32 AM Björn Blissing <bjorn.blissing at vti.se>
wrote:

> Hi,
>
> Today we discovered that our generated CPACK_PACKAGE_VERSION variables
> were broken.
> This is probably related to us updating to a newer version of CMake.
>
> Previously we generated this variable by setting the
> CPACK_PACKAGE_VERSION_MAJOR and CPACK_PACKAGE_VERSION_MINOR to fixed
> values, while CPACK_PACKAGE_VERSION_PATCH was set to variable name.
> This name was then replaced by running a custom target just before
> building. In this target the variable name got replaced with the current
> SVN revision number. This have worked the last years, but now the variable
> name just gets omitted when we run "generate" in CMake.
>
> A short example:
> ================
> cmake_minimum_required(VERSION 2.8.9)
> project (hello)
> add_executable(hello helloworld.cpp)
> set(CPACK_PACKAGE_VERSION_MAJOR "1")
> set(CPACK_PACKAGE_VERSION_MINOR "0")
> set(CPACK_PACKAGE_VERSION_PATCH "REPLACEME")
> include(CPack)
>
> Would result in the following strings in CPackConfig.cmake:
> -----------------------------------------------------------
> set(CPACK_PACKAGE_VERSION "1.0.REPLACEME")
> set(CPACK_PACKAGE_VERSION_MAJOR "1")
> set(CPACK_PACKAGE_VERSION_MINOR "0")
> set(CPACK_PACKAGE_VERSION_PATCH "REPLACEME")
>
>
> But with the CMake 3.12.2 this will be:
> ---------------------------------------
> set(CPACK_PACKAGE_VERSION "1.0")
> set(CPACK_PACKAGE_VERSION_MAJOR "1")
> set(CPACK_PACKAGE_VERSION_MINOR "0")
> set(CPACK_PACKAGE_VERSION_PATCH "REPLACEME")
>
>
> So our CPACK_PACKAGE_VERSION will omit the variable name, which in turn
> makes our custom target to fail.
>
> Our quick fix was to add the following line to our CMakeList.txt file:
> SET(CPACK_PACKAGE_VERSION
> "${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}")
>
> My question is: Is this change of behavior intended? Are only numbers
> allowed to be part of the CPack version variable?
>
> Regards
> Björn Blissing
>


-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190526/2e0843ca/attachment.html>