I suggest renaming variables in a separate PR.

I've separated it into a commit. If that's not enough I can create a new PR.

I'd suggest a separate PR. That said, what is the reason to rename this variable? It can be argued it's both curl and libcurl version, and since it has been CURL_ for a long time, why change now?

edit: CURL_ is also the namespace we use for curl-specific CMake variables. (And LIBCURL_PC_ but that is a separate, libcurl-specific namespace.) TL;DR: existing name looks fine to me.

CURL_VERSION will be initialized by project() (without the -DEV as suffix because the syntax rejects). The variables related to project() should be generated by project() IMO, though I'm not insist on it.

Edit: Since CMake 3.30, behaviour of variables generated by project has been changed. Though it doesn't affect <Project>_VERSION* now, I think it'd better not to set CURL_VERSION explicitly.

So, the renaming is related to setting the project(VERSION). Should this be extracted to a PR?

Oh, so project() is setting the CURL_VERSION and *_MAJOR/MINOR/PATCH variables automatically, but also differently depending on version and/or CMP policy. E.g. cmake 3.30.x is setting them.

Before this patch we already set CURL_VERSION to 8.11.0-DEV. This changes to 8.11.0 when using project().

What is the advantage of using project() for setting the CURL_VERSION variable? Why do we need this?

edit: link for reference: https://cmake.org/cmake/help/latest/command/project.html#options

wouldn't we need this to catch non-DEV versions?:

string(REGEX REPLACE "([0-9]+\.[0-9]+)\.([0-9]+.*)" "\\2" CPACK_PACKAGE_VERSION_PATCH "${LIBCURL_VERSION}")

Yes. I've tested both DEV and non-DEV versions. This works fine.

Would you want to do the renaming from LIBCURL_VERSION* to _cmake_version*?

CMAKE_VERSION is the version of CMake. But we could add an underscore prefix (with full lower-case)?

I meant rename to _curl_version_*, sorry.

I meant rename to _curl_version_*, sorry.

done