Generate cnats-config-version.cmake - #813
Conversation
…ion in find_package
|
|
||
| write_basic_package_version_file( | ||
| "${PROJECT_BINARY_DIR}/cnats-config-version.cmake" | ||
| COMPATIBILITY SameMajorVersion |
There was a problem hiding this comment.
@rolflussi I do not have much personal experience with cmake package management/discovery, but what I understood from https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html#generating-a-package-version-file, I think we should be using SameMinorVersion if binary compatibility is desired. Furthermore, binary compatibility may be broken even in patch releases (thus, NATS_VERSION_REQUIRED_NUMBER check), I am not sure what the best practice on this is.
@kozlovic do you have an opinion on this?
There was a problem hiding this comment.
I don't think we do (or should) break compatibility in a patch release. But yes, minor release may introduce new APIs, etc.. that may cause their local header file to not be in phase with the linked library (this is why we have some API to check for compatibility between the header and the lib's version).
There was a problem hiding this comment.
Thanks for your feedback. I'll change it to SameMinorVersion
There was a problem hiding this comment.
(I misspoke re: patch releases; I was thinking a hypothetical emergency patch that'd break the memory layout, but we'd just release it as a X.Y+1.0 from the X.Y branch.
* provide cnats-config-version.cmake to be able to define required version in find_package * change from requiring same major version to same minor version --------- Co-authored-by: Rolf Lussi <rolf.lussi@kistler.com>
|
Cherry-picked into v3.9.2 |
3 participants
Implementation of #812
Allows other cmake projects to use this library with a specific version:
The cnats-config-version.cmake will make sure that the correct major version and at least the defined minor version is available.