OSGeo / gdal

GDAL is an open source MIT licensed translator library for raster and vector geospatial data formats.
https://gdal.org
Other
4.93k stars 2.56k forks source link

[CMake] Version check fails #11315

Open SunBlack opened 4 days ago

SunBlack commented 4 days ago

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 commented 4 days ago

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 commented 3 days ago

GDAL config is generated with compatibility setting "same minor version": https://github.com/OSGeo/gdal/blob/1344d8ddd5438668d99568ae603fbfa439673d3a/gdal.cmake#L561-L564

SunBlack commented 3 days ago

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 commented 1 day ago

, 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?