[CMake] Version check fails

[SunBlack]

What is the bug?

In our CMake file we have this line:

find_package(GDAL 3.3 CONFIG REQUIRED)

But this fails in case we building a dev build of CMake

CMake Error at CMakeLists.txt:38 (find_package):
  Could not find a configuration file for package "GDAL" that is compatible
  with requested version "3.3".

  The following configuration files were considered but not accepted:

    C:/dev/dependencies/gdal/lib/cmake/gdal/GDALConfig.cmake, version: 3.11.0dev

Note: Had this issue already on our CI when checking our via

git clone  --depth 1 --branch v3.10.0 https://github.com/OSGeo/gdal.git .

Shouldn't the dev removed on the commits with a release tag? Didn't checked the CMake source in which cases the dev bill be added and when not.

Steps to reproduce the issue

See bug decription

Versions and provenance

Windows & Linux

Additional context

No response

[rouault]

Note: Had this issue already on our CI when checking our via

so the issue is not the dev suffix, right ?

I believe that find_package(GDAL 3.3 CONFIG REQUIRED) indicates that you want exactly version 3.3, so it is expected to fail with other 3.x

[dg0yt]

GDAL config is generated with compatibility setting "same minor version":

gdal/gdal.cmake

Lines 561 to 564 in 1344d8d

	write_basic_package_version_file(
	GDALConfigVersion.cmake
	VERSION ${GDAL_VERSION}
	COMPATIBILITY SameMinorVersion)

[SunBlack]

Note: Had this issue already on our CI when checking our via

so the issue is not the dev suffix, right ?

Wanted to mention with it: Even when checking out a tag, ${GDAL_VERSION} is 3.10.0dev and not just 3.10.0. So at first I thought it was due to suffix, but VERSION_LESS or VERSION_GREATER_EQUAL can handle it.

I believe that find_package(GDAL 3.3 CONFIG REQUIRED) indicates that you want exactly version 3.3, so it is expected to fail with other 3.x

No, for this the keyword EXACT exists.

@dg0yt Ahh forgot that this could be the reasons as most projects are not this strict. Is there any reason, why this is not SameMajorVersion? I'm not sure which deprecation cycle GDAL follows, but since our code works with GDAL 3.0 - 3.10 I assume that only things are added, but nothing is removed and ABI stability is irrelevant when building (since you are fresh linking and not just swap the binaries without relinking). Didn't checked it now, but I assume it is also not possible to pass version range, or? (As this is a CMake 3.19 feature)

[rouault]

, but nothing is removed and ABI stability is irrelevant when building (

There are sometimes C++ API breakage in the 3.x series (tend to affect "obscure" parts of the API)

With #11335 I believe there's nothing left preventing this ticket to be close?

[SunBlack]

, but nothing is removed and ABI stability is irrelevant when building (

There are sometimes C++ API breakage in the 3.x series (tend to affect "obscure" parts of the API)

Ah okay, in this case this makes sense. Do you know, how often this happens?

With #11335 I believe there's nothing left preventing this ticket to be close?

Mhm, I think there is room for improvement

• Version range support would be nice, so we could define a range, where we know there is breaking API change for us, as currently you get:

  CMake Error at CMakeLists.txt:38 (find_package):
    Could not find a configuration file for package "GDAL" that is compatible
    with requested version range "3.7...3.11".
  
    The following configuration files were considered but not accepted:
  
      C:/dev/dependencies/gdal/lib/cmake/gdal/GDALConfig.cmake, version: 3.10.0dev
  

• The error message could be improved so that you get a hint that only the same minor version is compatible and the same major version is not sufficient. Currently it is a bit irritating, that find_package(GDAL 3.7 MODULE REQUIRED) is fine with GDAL 3.10, but find_package(GDAL 3.7 CONFIG REQUIRED) not.

I think both would require changes on the part of CMake. I wrote a ticket to them and leave the ticket open here until it is clear whether something could be improved on the part of GDAL or not (in the latter case, the ticket could then be closed).