if version=latest, use the last tagged version in repository
eg:
CPMAddPackage(
NAME fibonacci
GIT_REPOSITORY https://github.com/cpm-cmake/testpack-fibonacci.git
VERSION latest
)
motivation:
this is common case for our setup, where for modules like gh:TheLartians/PackageProject.cmake , we just want to pickup the latest version. so i asked chatGPT: prompt: how to download the latest tag of a package with CPMAddPackage answer:
include(cmake/CPM.cmake)
CPMAddPackage(
NAME <package_name>
VERSION *
)
bing AI had something similar to say, so anyway I think this would be a useful enhancement.
Hey, thanks for the PR! I agree that being able to specify the latest version or even better, a version range (see #99), would be awesome and this PR could be setting some of the groundwork for that.
However we need to be careful with such a feature as it can result in broken projects if not implemented properly. E.g. if at some point breaking changes are introduced to PackageProject.cmake, all projects depending on the "latest" version would break. Therefore any implicit versioning feature would also need to use a package locking mechanism where the resolved version would be automatically placed and updated in the package lock file.
Let me know if you want to take on the locking mechanism as well, and need any pointers for that. Otherwise I'd hold off with merging this PR until a suitable mechanism is implemented.
version ranges would be very useful for any project following semantic versioning:
CPMAddPackage("gh:google/[email protected].*")
or
CPMAddPackage("gh:google/benchmark@1.*")
anyway it might be useful to fetch available versions of a tool anyway for diagnostic messages on version mismatch.
by locking do you mean something like this? https://docs.gradle.org/current/userguide/dependency_locking.html
by locking do you mean something like this?
Yes that or similar to the package-lock.json used by npm. In fact we already have a rudimentary package lock setup, however there is currently no automation to keep it in sync with changing dependency versions in the CMakeLists, which would be needed for this feature.